httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <DRugg...@primary.net>
Subject Re: Segfault in openssl's err_cmp when using SSLCryptoDevice and new SSLProxyMachineCertificateChainFile
Date Thu, 02 Feb 2012 19:02:59 GMT
On 1/19/2012 1:13 AM, Sander Temme wrote:
> Interesting... which version of OpenSSL?  Must be 0.9.7 or 0.9.8, because err_cmp() disappeared
after that.  And the signature doesn't match what we're seeing in the backtrace.  
>
> And which platform? Solaris?  SPARC or x86_64?

I tried building against 1.0.0g and get a new error (with or without the
new SSLProxyMachineCertificateChainFile directive).
[Thu Feb 02 12:48:48 2012] [error] Init: Failed to enable Crypto Device
API `chil'
[Thu Feb 02 12:48:48 2012] [error] SSL Library Error: 2164682865
error:81067071:CHIL engine:HWCRHK_INIT:unit failure
[Thu Feb 02 12:48:48 2012] [error] SSL Library Error: 638287981
error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed

Since this happens with every attempt to start, I suspect it has nothing
to do with the new directive and more to do with something I did on the
openssl build. Attempts to run this guy in dbx bomb out with SIGILL here:
  [1] _sparcv9_fmadd_probe(0x0, 0x1, 0x0, 0x82, 0xffffffff7ec00200,
0x6), at 0xffffffff7a96353c
  [2] OPENSSL_cpuid_setup(0x0, 0x0, 0x0, 0x1000, 0x0, 0x0), at
0xffffffff7a9631ec

If I force the ENV var OPENSSL_sparcv9cap=3, then things seem to chug
along and fail at the same point in the logs as above. Not sure where to
go from here or it it's even worth pursuing. I'm guessing openssl 1.0.0
isn't going to play nice in my environment.

> So the combination of directives causes some memory to be overwitten
> that ends up pointing outside httpd's allocated address space. Does
> the order of the directives matter? Which Engine if I may ask? A fix
> was applied to the CHIL Engine that removes a dangling cleanup
> function pointer which caused a segfault on startup on platforms that
> vary the address location in which libraries are loaded (RHEL 5 being
> a prime example). I don't remember off the top of my head which
> OpenSSL version got the fix. Can you reproduce with a non-optimized,
> debug/symbols enabled build of OpenSSL and Apache? With the latest
> versions of each? S. 

After some testing, order doesn't matter- same results regardless. I
have confirmed that the chil update (noted by you and Steve) is applied
to this version of openssl (looks like it was formally incorporated into
the one I'm using). Unfortunately, openssl doesn't have a
debug-solaris64-sparcv9-cc build option so I can't produce a debug
version of openssl. I did remove optomizations from httpd, though... I'm
going to try with 0.9.8t and see if anything is different.

-- 
Daniel Ruggeri


Mime
View raw message