[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svn commit: r1198930 - in /httpd/httpd/trunk: include/mod_core.h server/core.c server/main.c

Thanks, Rüdiger. Maybe this sheds some light on EVP_cleanup():


Seems libssl install algorithms into libcrypto and does not clean
up on termination which means EVP_cleanup sees data which is already gone.


> Am 03.08.2018 um 15:42 schrieb Ruediger Pluem <rpluem@xxxxxxxxxx>:
> On 08/03/2018 03:28 PM, Stefan Eissing wrote:
>> (I am trying to understand this issue, since someone reported probs
>> with mod_md/mod_ssl/some db drive init order related to openssl init.)
>> The the move from cleanup() to pre_cleanup() fixed this issue. It means (as I read it)
>> that something was happening in sub-pools cleanup()s that was out-of-order.
>> Looking at apr_crypto_init(), it registers the cleanup at the "root" pool,
>> does this give a clue?
>> So we might have:
>> - mod_ssl loading libssl, loading libcrypto
>>  cleanup at pool
>> - ...
>> - someone (indirectly) calling apr_crypto_init()
>>  cleanup at root pool
>> root pool destroy:
>>  sub pool destroy  
>>  -> mod_ssl cleanup called
>> -> apr cleanup called
> We have
> 1. ap_init_rng in main.c causes apr_crypto_init called with ap_pglobal
> 2. This causes apr__crypto_openssl_term to be registered as a cleanup with ap_pglobal.
> 3. mod_ssl is loaded via the pconf pool which is a child of ap_pglobal
> 4. The loading of mod_ssl triggers the loading of libssl via the dynamic linker.
> 5. libssl is initialized in ssl_hook_pre_config via
>          SSL_load_error_strings();
>          SSL_library_init();
> 6. The above seems to cause references to static data in libssl being saved in data structures
>   managed by libcrypto.
> 7. apr_pool_destroy(process->pool) in main.c:283 destroys the ap_pglobal which in turn
>   a) first destroys pconf
>   b) which causes mod_ssl to be unloaded
>   c) which cause libssl to be unloaded
> 8. The cleanups of ap_pglobal are now called, especially apr__crypto_openssl_term which
>   a) calls EVP_cleanup()
>   b) which tries to access the data stored in 6., but is gone since 7c)
> Using a pre_cleanup moves 8. before 7. and thus removes the issue.
> Regards
> Rüdiger