[OTR-dev] libotr: main thread blocked when generating privkey in another thread and entropy is low

[Martin Milata]

On Mon, Dec 16, 2013 at 21:19:31 -0500, Ian Goldberg wrote:
> On Tue, Dec 17, 2013 at 01:36:52AM +0100, Martin Milata wrote:
> > Hi!
> > 
> > I'm writing a program that uses libotr-4.0.0 and encountered a problem
> > when trying to perform key generation in backtround thread.
> > 
> > When the key generation is running and another OTR query is received by
> > libotr the program crashes with following stacktrace:
> > 
> > ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed.
> 
> What's supposed to happen is when you try to generate the key for the
> same account the second time, otrl_privkey_generate_start will return
> gcry_error(GPG_ERR_EEXIST), and *newkeyp is set to NULL.  Are you
> checking for this?  The second OTR query should not cause a launch of a
> background thread at all.
>
> Or do you mean you received OTR Query messages for two _different_ local
> accounts?
>
> But more generally, libotr has no way of knowing what threading library
> your application is using, so your application may well need to call the
> gcry_control to enable multithreading.  Does the problem go away if you
> do that before calling OTRL_INIT?

This happens despite checking the otrl_privkey_generate_start return
value. I think it would happen for two different local accounts as well.
In any case, calling gcry_control beforehand worked, howerver there
still exists similar problem.

Again, when key is being generated in the background and another OTR
query arrives and the system is very low on entropy (typical for virtual
servers), the main thread blocks until the private key is generated:

Keygen thread:
#0  poll
#1  _gcry_rndlinux_gather_random
#2  read_random_source
#3  _gcry_rngcsprng_randomize
#4  _gcry_random_bytes_secure
#5  dsa_generate_ext
#6  _gcry_pk_genkey
#7  otrl_privkey_generate_calculate
#8  COtrMod::GenKeyThreadFunc
#9  start_thread
#10 clone

Main thread:
#0  __lll_lock_wait
#1  _L_lock_790
#2  pthread_mutex_lock
#3  lock_pool
#4  initialize
#5  _gcry_rngcsprng_randomize
#6  _gcry_random_bytes_secure
#7  otrl_dh_gen_keypair
#8  otrl_auth_start_v23
#9  otrl_message_receiving
#10 COtrMod::OnPrivMsg
...continues

There doesn't appear to be a simple solution for this except advising
the users to install an entropy-gathering daemon such as haveged on the
VM.

Cheers,
Martin