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