We are seeing the deadlock in FIPS 2.0. (1.0.1c + fips-2.0 and using
AES256-SHA256 if that matters.) DRBG's auto reseeding (after 2^24 operations)
causes it. Here is the simplified backtrace.
fips_drbg_bytes()
CRYPTO_w_lock(CRYPTO_LOCK_RAND)
FIPS_drbg_generate()
drbg_reseed()
fips_get_entropy()
drbg_get_entropy()
ssleay_rand_bytes()
CRYPTO_w_lock(CRYPTO_LOCK_RAND)
Obviously, a simple workaround is to register the locking callback that uses
the recursive lock (e.g., PTHREAD_MUTEX_RECURSIVE_NP). However, I can't find
such locking requirement in OpenSSL FIPS 2.0 User Guide. (And w/o FIPS 2.0,
OpenSSL clearly avoids the recursive lock.)
Are we not initializing FIPS properly? If so, what's missing? (We are not
registering our own entropy callbacks.) Or, is this a simple oversight in FIPS
locking???
--- Seiichi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
