You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/06/20 15:09:46 UTC

DO NOT REPLY [Bug 20951] New: - Locking upcalls not set for SSLCryptoDevice chil

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20951>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20951

Locking upcalls not set for SSLCryptoDevice chil

           Summary: Locking upcalls not set for SSLCryptoDevice chil
           Product: Apache httpd-2.0
           Version: 2.0.46
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: adunn@ncipher.com


Using httpd-2.0.46-win32-src.zip, in modules/ssl/ssl_engine_init.c:

On line 278, ssl_util_thread_setup is called which eventually calls
CRYPTO_set_locking_callback. Prior to this, no locking callback is set.

However, on line 272, ssl_init_Engine is called which, when using the chil
openssl engine, eventually gets to this chunk of code in hw_init
(openssl-0.9.7b/crypto/engine/hw_ncipher.c):

        /* Check if the application decided to support dynamic locks,
           and if it does, use them. */
        if (disable_mutex_callbacks == 0)
                {
                if (CRYPTO_get_dynlock_create_callback() != NULL &&
                        CRYPTO_get_dynlock_lock_callback() != NULL &&
                        CRYPTO_get_dynlock_destroy_callback() != NULL)
                        {
                        hwcrhk_globals.mutex_init = hwcrhk_mutex_init;
                        hwcrhk_globals.mutex_acquire = hwcrhk_mutex_lock;
                        hwcrhk_globals.mutex_release = hwcrhk_mutex_unlock;
                        hwcrhk_globals.mutex_destroy = hwcrhk_mutex_destroy;
                        }
                else if (CRYPTO_get_locking_callback() != NULL)
                        {
                        HWCRHKerr
(HWCRHK_F_HWCRHK_INIT,HWCRHK_R_DYNAMIC_LOCKING_MISSING);
                        ERR_add_error_data(1,"You HAVE to add dynamic locking 
callbacks via
CRYPTO_set_dynlock_{create,lock,destroy}_callback()");
#if 1 /* This is a HACK which will disappear in 0.9.8 */
                        hwcrhk_globals.maxmutexes    = 1; /* Only have one lock 
*/
                        hwcrhk_globals.mutex_init    = hwcrhk_static_mutex_init;
                        hwcrhk_globals.mutex_acquire = hwcrhk_static_mutex_lock;
                        hwcrhk_globals.mutex_release = 
hwcrhk_static_mutex_unlock;
                        hwcrhk_globals.mutex_destroy = 
hwcrhk_static_mutex_destroy;
#else
                        goto err;
#endif
                        }
                }

No dynamic locking callbacks have been set so it checks,
if (CRYPTO_get_locking_callback() != NULL),
yet no static locking callback has been set either as
ssl_util_thread_setup has still to be called.
It therefore proceeds with no hwcrhk mutex calls which causes an assertion 
failure in ncipher's software.

Calling ssl_util_thread_setup before ssl_init_Engine results in the
hwcrhk_static_* calls being used and Apache functioning normally.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org