gpg-agent blocking in genkey etc.

[Werner Koch]

Hi!

yesterday we tracked down a bug in gpg-agent which inhibited a second
connection to the gpg-agent while the gpg-agent was creating a key.

After some more testing we will soon release libgpg-error 1.25 and gnupg
2.1.16 to fix those blocking problems.

There are to reasons for the problem:

The key generation requires reading from /dev/random.  The first step
Libgcrypt does is to set a mutex for its internal random pool.  If a
second connection (i.e. nPth thread) need to get a random number (also
key generation but also for signing) it would block right at that mutex.
That would be fine because we want to serialize access to the RNG.
However an arbitrary third thread (e.g. another connection) would not be
able to run because nPth (our user land threding library) did not know
about lock inside Libgcrypt and thus it can't schedule any threads.

The solution to this is straightforward: Libgpg-error (which actually
does the locking) has been fixed to also use its "system call clamp" for
the locking calls.  This clamp is set by gpg-agent to connect
libgpg-error with the Pth library.  That thingy has originally been
implemented for Libgcrypt's estream I/O system but it needs to be used
for all other blocking calls as well.  The fix will go into Libgpg-error
1.25.

Now that this has been solved things should work.  But they won't:
Libgcrypt reads from /dev/random and that is, as we all know, a blocking
system call.  Same problem again.  Fortunately Libgcrypt uses select
before the read and calls back into gpg-agent every few seconds with a
PROGRESS notification.  gpg-agent now catches this notification and
takes a short nap (100ms via npth_usleep) so that other threads can run.
The delay is not a problem because it gives the kernel time to collect
entropy.  This fix will be released with 2.1.16.

That solution works but gpg-agent is not every responsive because
re-scheduling takes places only every few seconds when a PROGRESS
notification is received.  A better solution is to use a system call
clamp in Libgcrypt as well.  That can be easily done by reading the
clamp already known to libgpg-error.  However, there are a few
peculiarities which won't allow us to do this in an updated Libgcrypt
1.7.  Thus the final fix will work only with the not-yet released
Libgcrypt 1.8.0.  GnuPG 2.1.16 will be prepared for that.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161112/d830e7a7/attachment.sig>