httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <>
Subject Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
Date Wed, 06 Dec 2006 17:57:42 GMT
Frank wrote:

> EVP_CIPHER_CTX_init (& ctx);
> EVP_EncryptInit (& ctx, EVP_bf_cbc (), key, iv);
> EVP_EncryptUpdate (& ctx, outbuf, & olen, inbuff, n);
> EVP_EncryptFinal (& ctx, outbuf + olen, & tlen);
> Because 'EVP_CIPHER_CTX_init' is 'slow', I want to call it once! (Yes! I 
> can call it for every request and then (I think) I am on the safe side, 
> but I do not want this because there are MANY requests!)
> So my code has to be thread safe, as Apache might be compiled with 
> thread support! To make it thread safe 
> told me:

These functions a generally thread safe AFAIK so long as you are not 
using an engine / cyptocard or something shared.  If its just a basic 
memory in memory out transform it should be pretty clean of locking.

Its only stuff like SSL session cache and SSL_CTX and registrations 
schemes (cipher registration, digest registration, etc...) which use 
locking as they are shared concurrently.

But I understand your point.  Its a necessity because the API contract 
says that is what you must do.

> "OpenSSL can safely be used in multi-threaded applications provided that 
> at least two callback functions are set."
> This means the two functions 'CRYPTO_set_locking_callback' and 
> 'CRYPTO_set_id_callback'!
> These two functions are being called from mod_ssl by the 
> ssl_init_Module-function (via ssl_util_thread_setup, which creates some 
> thread mutexes and calls the both functions) without testing whether 
> they have already being called or not.
> My question is: How does this interfere with my module? How can I ensure 
> that only one of us (mod_ssl or my module) is calling these both 
> functions? I cannot believe that there is no problem when my module 
> creates some thread mutexes and mod_ssl does it too...

Of course it is necessary to arbitrate the load and unloading of the 
OpenSSL libraries.  Where loading really means the initial configuration 
that OpenSSL requires to initialize itself before it achieves maximal 

This is true of any programming paradigm.  If something it thread-unsafe 
until you configure it correctly to be thread-safe, you have to 
serialize all usage upto the point it becomes safe.  This includes 
calling functions to initialize the safety mechanism.

You also can't go and change the locking policy while there maybe one or 
more active users of the old/existing policy.  From a practical 
standpoint its impossible to tell how many users there are once the 
first user gets stuck into application work.  So you are correct, you 
can't blindly can go overwriting the policy with 
CRYPTO_set_locking_callback() to point to your mutexes.

 > P.S.: I still think there is need for a test routine like
 > 'ssl_is_thread_safe_maker_on()'.

Agreed.  The problem is reduced to serializing the setting of the 
locking policy, which is reduced to the apache http server framework 
providing a non-performance critical locking mechanism and a boolean 
flag.  Then each mod_xxxx user locks that external lock, checks the 
external flag, if flag not set, configure locking policy in openssl, set 
flag and unlock.  The apache framework needs to be the arbitrator here 
by holding the lock and flag in a namespace accessible by all modules.

It does not matter which application wins to set the policy, just so 
long as a policy it setup.  But it would be helpful if both mod_ssl and 
mod_frank would agree on the same policy (OpenSSL kind of gives you a 
few options here)


View raw message