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

[Andy Polyakov via RT]

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