After digging deeper I realized that the |Sha1_Update()| crypto function zeroes the registers. More specifically - the code zeroing the registers is in the |HASH_BLOCK_DATA_ORDER| macro (translated to |sha1_block_data_order_avx()| function):

sha1_block_data_order_avx()
movaps xmmword ptr [rsp+40h],xmm6 movaps xmmword ptr [rsp+50h],xmm7 movaps xmmword ptr [rsp+60h],xmm8 movaps xmmword ptr [rsp+70h],xmm9 movaps xmmword ptr [rsp+80h],xmm10 mov r8,rdi mov r9,rsi mov r10,rdx vzeroall The |VZEROALL| instruction zeroes all |XMM| registers up to 15 while only |XMM6-XMM10| are stored to stack (and resored later on).

Oops! This is indeed problem. Analysis is correct. And solution in this case is to switch to vzeroupper. And even sha512-x86_64.pl module is affected. I've committed patches to master, 1.0.2 and 1.0.1.

Could you, please, look and comment it, or possibly advice some workaround (something like the "|no-sse2|" config option)?

There is no way to selectively disable SIMD code during config in x86_64/x64 builds, only to disable all assembly modules with no-asm. A bit counterintuitive, it's possible to "fool" the build procedure by dropping nasm.exe copy prior 2.09 on %PATH%. This would prevent specifically AVX code paths from being compiled. It's also possible to disable AVX support as run-time by setting OPENSSL_ia32cap environment variable to ~0x1000000000000000.

Thanks for report.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to