httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: mod_ssl broken as DSO in HEAD
Date Tue, 17 Jun 2003 02:14:45 GMT
At 08:13 PM 6/16/2003, Justin Erenkrantz wrote:
>The change to move OpenSSL's initialization to ssl_hook_pre_config is busted when mod_ssl
is a DSO.  It will try to call all of the OpenSSL init sequences twice which I don't believe
OpenSSL supports.

We may need to register proper 'cleanups' to 'unload' all of the engines, as you
point out in this problem;

>Namely, that is a problem for ENGINE_load_builtin_engines() which will 'detect' conflicting
engine IDs:
>
>(dbx 1) where
> [1] 0xdd32cbe0(), at 0xdd32cbdf
> [2] CRYPTO_thread_id(), at 0xddab652f
> [3] ERR_get_state(), at 0xdda72732
> [4] ERR_put_error(0x26, 0x78, 0x67, 0xddac1ca8, 0x72), at 0xdda71e49
> [5] engine_list_add(0x81e9720), at 0xdda586f1
> [6] ENGINE_add(0x81e9720), at 0xdda58a5d
> [7] ENGINE_load_dynamic(), at 0xdda5b78e
> [8] ENGINE_load_builtin_engines(), at 0xdda5a565
>=>[9] ssl_hook_pre_config(pconf = 0x8197d28, plog = 0x81d5e20, ptemp = 0x81dbe38),
line 245 in "mod_ssl.c"
> [10] ap_run_pre_config(0x8197d28, 0x81d5e20, 0x81dbe38), at 0x80dcd07
> [11] main(argc = 2, argv = 0x8046a70), line 640 in "main.c"
>
>ERR_put_error's third argument (reason) is 0x67 (103) which is ENGINE_R_CONFLICTING_ENGINE_ID.
 0x72 (114) is the line number that has that ID in crypto/engine/eng_list.c.
>
>So, this code path makes sense (to me) since if I break on the debugger, I see that ENGINE_load_builtin_engines()
is called twice since ssl_hook_pre_config is called twice.

Right.  What is more interesting (as a DSO) is that our module, and ergo the
SSL library, should have been unloaded and reinitialized.  Apparently we
can't count on that behavior, though.

>Note that I can't reproduce this SEGV running under dbx, but can reproduce out of the
debugger (this trace is from a core).  This leads me to believe that we are having a double-init
problem.
>
>Since pre_config doesn't get the process info, we can't use the userdata trick to prevent
double initialization.  My solution would be to grow the pre_config hook to get the process
info.  But, that can't be what was intended.  =)  -- justin

Well, if it isn't done before pre-config, the entire ENGINE support code in the
command handler for SSLCryptoDevice is borked.  I know, I already spent 
two days there.

If we force the SSL Library to stay loaded (reliably, across platforms) between
startup phases (with the SSL module itself unloading and reloading - ick), 
then saving the initialization in pprocess might be a viable alternative, but
where?  register_hooks is no better than pre_config in this regard.

Or we simply work out an ENGINE_unload_engines() as a cleanup.  But of
course, OpenSSL doesn't really like to be cleared and restarted from scratch,
so I don't know if this is really trivial or a nightmare.

Bill



Mime
View raw message