On Wed, Aug 22, 2012, Seiichi Tatsukawa wrote: > 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??? >
Thats a bug in the FIPS capable OpenSSL. It should be using a version of ssleay_rand_bytes() which doesn't use a CRYPTO_LOCK_RAND lock. I'll look into fixing it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
