Hi Everyone,
I'm catching a crash with Nettle 3.5.1 on a Core-i7 8700 configured with --enable-x86-aesni and --enable-x86-sha-ni. I verified the compiler supports both AESNI and SHA.
Illegal instruction (core dumped) FAIL: hkdf PASS: salsa20 Illegal instruction (core dumped) FAIL: sha1 Illegal instruction (core dumped) FAIL: sha224 Illegal instruction (core dumped) FAIL: sha256
The machine is not configured with --enable-fat because of build failures on other platforms. On other platforms, --enable-fat causes SHA to be built even when the compiler does not support SHA. To avoid the compile error I dropped --enable-fat .
So my question now is, how do I enable AES and SHA at compile time depending on the compiler support, and enable runtime switching?
Thanks
-------
Here is the logic I was trying to use. It accommodates both Linux and Solaris.
AESNI_OPT=$("$CC" "$CFLAGS" -dM -E -maes - </dev/null 2>&1 | grep -i -c "__AES__") SHANI_OPT=$("$CC" "$CFLAGS" -dM -E -msha - </dev/null 2>&1 | grep -i -c "__SHA__")
if [[ "$AESNI_OPT" -eq 1 ]]; then echo "Compiler supports AES-NI. Adding --enable-x86-aesni" CONFIG_OPTS+=("--enable-x86-aesni") fi
if [[ "$SHANI_OPT" -eq 1 ]]; then echo "Compiler supports SHA-NI. Adding --enable-x86-sha-ni" CONFIG_OPTS+=("--enable-x86-sha-ni") fi
# Crash on Solaris machines with --enable-fat #if [[ "$IS_IA32" -ne 0 ]]; then # echo "Using runtime algorithm selection. Adding --enable-fat" # CONFIG_OPTS+=("--enable-fat") #fi
On Sat, Feb 1, 2020 at 8:38 PM Jeffrey Walton noloader@gmail.com wrote:
... I'm catching a crash with Nettle 3.5.1 on a Core-i7 8700 configured with --enable-x86-aesni and --enable-x86-sha-ni. I verified the compiler supports both AESNI and SHA. ...
Here is the logic I was trying to use. It accommodates both Linux and Solaris.
AESNI_OPT=$("$CC" "$CFLAGS" -dM -E -maes - </dev/null 2>&1 | grep -i -c "__AES__") SHANI_OPT=$("$CC" "$CFLAGS" -dM -E -msha - </dev/null 2>&1 | grep -i -c "__SHA__")
if [[ "$AESNI_OPT" -eq 1 ]]; then echo "Compiler supports AES-NI. Adding --enable-x86-aesni" CONFIG_OPTS+=("--enable-x86-aesni") fi
if [[ "$SHANI_OPT" -eq 1 ]]; then echo "Compiler supports SHA-NI. Adding --enable-x86-sha-ni" CONFIG_OPTS+=("--enable-x86-sha-ni") fi
# Crash on Solaris machines with --enable-fat #if [[ "$IS_IA32" -ne 0 ]]; then # echo "Using runtime algorithm selection. Adding --enable-fat" # CONFIG_OPTS+=("--enable-fat") #fi
This is what is confusing me:
--enable-fat Enable fat library build (default=no) --enable-arm-neon Enable ARM Neon assembly. (default=auto) --enable-x86-aesni Enable x86_64 aes instructions. (default=no) --enable-x86-sha-ni Enable x86_64 sha_ni instructions. (default=no) --enable-mini-gmp Enable mini-gmp, used instead of libgmp.
SHA-NI is off by default. The build system should not be trying to build SHA-NI unless I explicitly enable it.
Jeff
Jeffrey Walton noloader@gmail.com writes:
Hi Everyone,
I'm catching a crash with Nettle 3.5.1 on a Core-i7 8700 configured with --enable-x86-aesni and --enable-x86-sha-ni. I verified the compiler supports both AESNI and SHA.
Illegal instruction (core dumped) FAIL: hkdf PASS: salsa20 Illegal instruction (core dumped) FAIL: sha1 Illegal instruction (core dumped) FAIL: sha224 Illegal instruction (core dumped) FAIL: sha256
Note that --enable-x86-sha-ni controls if the output binaries use the instructions in question. It's unconditional, in effect, you're telling configure "I intend to only ever run the resulting binaries on processors that support these instructions". And then it appears your processor actually don't have them, and crashes in the expected way.
The way to enable use conditionally depending on actual processor features at runtime, is to use --enable-fat.
Support in the tool chain (actually, it's the assembler rather than the C compiler that matters) is a prerequisite, but doesn't say anything about processor support.
Regarding the default --enable-arm-neon=auto, that's is a bit special, but I think the reason I did it that way is
(i) neon is pretty common on the ARM variants that are relevant for Nettle, and
(ii) for embeddded systems it seems more common that what's supported by the cross assembler corresponds to what's actually supported on the target processor. E.g., there are pseudo ops like .fpu = neon which controls which instructions are accepted.
I'm can't really say that's the best default for ARM either, but I haven't seen any reports of it causing problems. I think it would cause a lot of trouble if done the same way for x86.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Jeffrey Walton -
nisse＠lysator.liu.se