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]