[openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

[Puckett, Rick via RT]

Andy,

Thank you for the information and feedback.  As for using the patch, I can only use officially released versions (tar archives) downloaded from the OpenSSL website.  If the patch is incorporated in the next release, like 1.0.2e -- which should be any day now :-) -- then I'll get to use it. Until then I'll configure using "sparcv7" or try the "no-asm" option you mentioned next time I build.

I greatly appreciate you and the OpenSSL team looking into this and am happy I could, in some small way, help out. If there's something else I can do, please let me know. 

- Rick

-----Original Message-----
From: Andy Polyakov via RT [mailto:rt at openssl.org] 
Sent: Monday, July 20, 2015 9:03 AM
To: Puckett, Rick (IS)
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

> I ran the truss command line you specified on the Sun T-3 and had to kill -9 the process as Ctrl-C and Ctrl-Z did not work. Attached is the truss.log output and below are the last few lines of that file where the process was hung up.

truss.log also effectively confirms the hypotheses.

> Setting OPENSSL_sparcv9cap to "0x20" (or even "0") allowed the program to complete (the code looks like it bypasses the probes if this is set to anything), though I don't know the operational ramifications of any value. 

You're correct that variable in question bypasses capability detection.
Whole idea behind capability detection is to provide best performance.
But setting wrong value can also cause crashes [because you'd be effectively forcing CPU to execute instructions it doesn't support]. For reference 0x20 is value that would normally have been set on T3 and means "use VIS3 extensions". The referred extensions are used for GHASH (~4.5x improvement) and BN (~2x improvement for RSA2048). Improvement coefficients are for T3 and relative to OPENSSL_sparcv9cap being set to 0.

> I applied the patch you sent and configured/compiled using "solaris-sparcv9-gcc" and the program completes normally.
> 
> As I am unable to use patched/unofficial code for our operational 
> needs,

What is criteria for being "official"? Explicitly released as tar-ball or just commit to repository?

> what I did last week is use the following option to the OpenSSL Configure script "solaris-sparcv7-gcc" or "solaris-sparcv7-cc" (we use both GCC and Sun C) and that seemed to fix/bypass the problem on the T-3.

That would do the trick, but under the circumstances you would be better off configuring with no-asm. This way you at least tell compiler to target SPARCv9.