Re: FIXED - CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)

[Sander Temme]

On Nov 21, 2008, at 11:12 AM, Massimiliano Pala wrote:

Hi Sander,

I debugged the init process and it seems that you were right. The
disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it
is due to initialization, at this point...

... looked into that, and... et voilas! Found the problem! The PRE
commands were wrong. Indeed the following:

        5.engine_pre = THREAD_LOCKING:1

caused the disable_mutex_callbacks to be set to 1, therefore no
callbacks were used! Ahhhh... what a nightmare! If you want to be
sure, you can set it to 0:

        5.engine_pre = THREAD_LOCKING:0

Przemek, this should solve also your problem - so you can enable
multiple threads and get rid of your 'lock' around the signing
function.

I think that the config variable should have been called:

        DISABLE_THREAD_LOCKING


is set to 1.. which should be the contrary (developer's error ?).

because if THREAD_LOCKING is set to 1 - then the disable_mutex_callbacks

Index: engines/e_chil.c
===================================================================
RCS file: /home/openssl/cvs/openssl/engines/e_chil.c,v
retrieving revision 1.9
diff -u -r1.9 e_chil.c
--- engines/e_chil.c    19 Nov 2008 14:21:26 -0000      1.9
+++ engines/e_chil.c    21 Nov 2008 19:24:37 -0000
@@ -164,11 +164,11 @@
                ENGINE_CMD_FLAG_STRING},
        {HWCRHK_CMD_FORK_CHECK,
                "FORK_CHECK",
-               "Turns fork() checking on or off (boolean)",
+               "Turns fork() checking on (non-zero) or off (0)",
                ENGINE_CMD_FLAG_NUMERIC},
        {HWCRHK_CMD_THREAD_LOCKING,
                "THREAD_LOCKING",
-               "Turns thread-safe locking on or off (boolean)",
+               "Turns thread-safe locking on (0) or off (non-zero)",
                ENGINE_CMD_FLAG_NUMERIC},
        {HWCRHK_CMD_SET_USER_INTERFACE,
                "SET_USER_INTERFACE",

Yes, this is confusing. The problem is that it's been like this for years and years, so you can't just turn the name or value around like that. At least not in the Stable branch. I think that would cause almost as much confusion as the present situation. I would suggest a documentation fix, like so:

Very confusing... and besides, it should give out some warning!!! Anyhow,

now the callbacks are called, and the server seems to run pretty ok
with a relatively large amount of threads (150). But I still have
to stress-test it...

Thanks to all of you who helped me - now I have a single file with
the code for OpenSSL and pthreads, both static and dynamic locks..

Shall we include it into OpenSSL ?

        void OpenSSL_pthread_init( void );

.. that would make it more usable for the average developer! :D

S.

--
[EMAIL PROTECTED]              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

We discussed this a while back, when I proposed setting the callbacks from the CHIL engine as a fallback option when the application didn't provide them. It breaks down on platforms where, for instance, pthreads are scarily broken. Howerver, it would be neat if OpenSSL could provide this scaffolding for the vast majority of users who have a working implementation.

smime.p7s
Description: S/MIME cryptographic signature