Then that stub needs to be used by everyone that also uses OpenSSL, and for Linux that means adding the stub to the LSB before any vendors adopt it, and so forth...
Initialization of locks at library (or in the case of static linking, application) load time is not rocket science and is being done in thousands of standard/system libraries today. That is really the only place you can do it and *not* have the problem that is being discussed. On Jun 25, 2010, at 10:20 AM, Rene Hollan wrote: > 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: [email protected] on behalf of Mark Phalan > Sent: Fri 6/25/2010 5:20 AM > To: [email protected] > Cc: [email protected] > 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 [email protected] > Automated List Manager [email protected] > > ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
