Thanks for the feedback on my patch - it includes locking in OBJ_NAME_cleanup 
and OBJ_NAME_remove, which seems to cover deinitialization.  Where am I missing 
other cleanup that is not being properly mutexed?

Certainly libraries could do bad things (like incorrectly using 
CRYPTO_NUM_LOCKS directly), but the libraries in this case are not taking any 
unusual action.  SSL_library_init is not documented to be un-thread-safe, for 
instance.

Also please note that ERR_remove_state is documented to be REQUIRED to be 
called by terminating threads.  And yet it is one of the calls which is 
un-thread-safe.  Given that, how would it be possible to write any threaded 
OpenSSL library with the current version which is not subject to thread-safety 
crashes?


 
-----Original Message-----
From: Stephen Henson via RT [mailto:[email protected]] 
Sent: Tuesday, July 07, 2009 4:32 PM
To: John Wilkinson
Cc: [email protected]
Subject: [openssl.org #1743] crasher due to lack of threadsafety on names_lh 

> [[email protected] - Tue Jul 07 23:01:13 2009]:
> 
> That's a useful tip, perhaps, but if the underlying calls are embedded
> in a third-party libraries, such as handled by cURL etc, the end user
> has no choice as to when they're being initialized.
> 
> Of course since
> multiple third-party libraries could be involved (which have no
> knowledge of each other), it's only possible to fix this issue in
> OpenSSL itself.
> 

Only certain issues can be handled in OpenSSL. Your fix handles
algorithm initialisation but not cleanup which is problematical.

Third party libraries can do things which break others in many different
ways. 

Setting the locking callbacks is one way to produce a race condition for
example.

Also adding a new lock is not something which can be done in a stable
branch because it causes nasty binary compatibility issues. 

The reason for that is that many applications use CRYPTO_NUM_LOCKS
instead of Crypto_num_locks() to get the number of locks. If they do
that and we add a new lock such applications will crash because an
attempt will be made to use a lock out of range.

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
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to