Frank wrote:
EVP_CIPHER_CTX ctx;
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
http://www.openssl.org/docs/crypto/threads.html 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
thread-safety.
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)
Darryl
