Jeffrey Walton <[email protected]> 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
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
