httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject Re: mod_ssl broken as DSO in HEAD
Date Tue, 17 Jun 2003 17:17:56 GMT
Hi there,

On June 16, 2003 10:14 pm, William A. Rowe, Jr. wrote:
> 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;

If things really are supposed to initialise (and unload) two times on 
startup, then I guess this is what you should do for openssl too.

> 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.

Depending on what gets initialised, there are a variety of things you 
might need to unload from openssl's point of view. However, this is 
usually an issue for people from a memory leak point of view, not a 
double initialisation. Potential issue: in a few places, openssl uses a 
global "is_set" variable to handle first-time initialisation of callbacks 
(eg. malloc). The idea is that once they're set, they can't be overriden. 
If you don't need to do *that* twice on startup, there's no problem. If 
you do, then it shouldn't matter *provided* you can live without error 
checking - if it fails then the (correct) global is still set from the 
previous initialisation, and if it succeeds then the globals needed 
setting anyway. Of course if it fails on the first initialisation then 
you have a bug that you'll never spot ... BTW: this is only for stuff 
where you are providing callback overrides for memory management, thread 
locking, error stacks, etc.

> 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.

<gulp> SSLCryptoDevice ... I don't like the sound of that ;-)

> 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.

This can be done easily enough, it's just a case of knowing what bits you 
need to clean up. What is beyond my reach however is a way of convincing 
Apache to run in one process and start up and close down cleanly - this 
is normally the easiest way to check for missing cleanups because they 
show up as leaks. I could otherwise give you some tips on cleanup 
sequences, but without a way of checking the cleanup code for leaks we'd 
be acting on faith that the sequence is (a) complete, and (b) the minimum 
necessary (no point putting redundant calls in and risking extra static 

Let me know if, and how, I can help. If you want to hunt around yourself, 
check out the "apps_startup()" and "apps_shutdown()" macro definitions 
inside apps/apps.h in the openssl source. You may not need all of those 
cleanups, and of course YMMV :-)


Geoff Thorpe

View raw message