Then you provide an OpenSSL stub that these plugins actually link against that lock the initialization of the real OpenSSL dlopen().
Ugly, perhaps, but you take the hit once. You are still left with the problem of using the same threading model that these plugins use, but you have that problem BETWEEN them as well, and could probably presume as to what it is for your execution environment. -----Original Message----- From: owner-openssl-...@openssl.org on behalf of Mark Phalan Sent: Fri 6/25/2010 5:20 AM To: openssl-dev@openssl.org Cc: msw...@apple.com Subject: Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. > > As you said so yourself, and I quote: "When both an application and a > library ([...]) both initialize and register their own threading functions, > bad things happen and the application can crash.") > Indeed. Spot on, I'd say. > > That is /exactly/ why OpenSSL places the ability, and hence also the > responsibility [which is the evil siamese twin of 'ability'], to _provide_ > an singular set of locking operations to the OpenSSL library itself for its > use. > These are > CRYPTO_set_lock_callback > CRYPTO_add_locking_callback > CRYPTO_set_dynlock_create_callback > CRYPTO_set_dynlock_lock_callback > CRYPTO_set_dynlock_destroy_callback > and you must call those at library setup time, say, around the same time you > invoke ERR_load_crypto_strings(). Except setting up locking at library setup time is inherently racy and *cannot* be done safely. The *only* safe place to setup locking callbacks is from the application. libraries cannot safely setup the locking callbacks. Just to make it clear why this is a problem imagine two threads running on Solaris each concurrently dlopening a plugin. Each plugin is linked against OpenSSL and tries to be a good citizen by setting the locking callbacks. They have no way to synchronize and thus no way to avoid racing against each other. As was noted elsewhere in the thread at least OpenSSL needs to provide way to safely (I think atomic test and set was mentioned) set the locking callbacks. I think it would also be nice if OpenSSL could have a compile time option to set default locking operations using the native threading model for the platform its being compiled on. I imagine that for most of the Linux/Unix/BSD etc this would be desirable. -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
