The Crypto++ code already tries to detect whether intrinsics are available
or not at runtime, the problem is that detection is not always correct. The
function is in file cpu.cpp, the last line I pasted below is setting the flag
for AESNI. Westmere hardware is one platform I know of that does not have
intrinsics available, but the code below sets the flag indicating it does,
causing an illegal instruction crash if AES code is used. Because of this, I
have disabled AESNI at compile time. I don't know enough about the bits being
checked in these HW registers to know how to fix the runtime check. void
DetectX86Features()
{
word32 cpuid[4], cpuid1[4];
if (!CpuId(0, cpuid))
return;
if (!CpuId(1, cpuid1))
return;
g_hasMMX = (cpuid1[3] & (1 << 23)) != 0;
if ((cpuid1[3] & (1 << 26)) != 0)
g_hasSSE2 = TrySSE2();
g_hasSSSE3 = g_hasSSE2 && (cpuid1[2] & (1<<9));
g_hasAESNI = g_hasSSE2 && (cpuid1[2] & (1<<25));
.
.
.
DetectX86Features()
From: Jeffrey Walton <[email protected]>
To: [email protected]
Cc: [email protected]
Sent: Sunday, December 28, 2014 7:40 PM
Subject: Runtime AES-NI detection (was Re: Illegal Instruction)
> I have had the same code run fine on one hardware platform, and
> crash on another with an illegal instruction. DIsabling AESNI intrinsics
> solved the problem, but it also means you won't get the performance
> boost of the AESNI instruction set on hardware that has it.
This issue creeps in on occasion. See, for example, "Failing on call to
_mm_loadu_si128() with AESNI intrinsics enabled",
http://stackoverflow.com/q/22100851/608639.
The solution is to select the implementation at runtime, and not compile time.
I'm not sure if that's a planned feature.
Jeff
On Monday, December 15, 2014 9:33:19 AM UTC-5, Rod wrote:
I have had an issue with an illegal instruction as well, and it was tied to
use of the AESNI intrinsics. There is code in Crypto++ to read some machine
registers to determine whether the registers and instruction set for AESNI are
present in the hardware, but it does not always detect correctly. I have had
the same code run fine on one hardware platform, and crash on another with an
illegal instruction. DIsabling AESNI intrinsics solved the problem, but it
also means you won't get the performance boost of the AESNI instruction set on
hardware that has it.
A better solution would be to fix the hardware detection code, but I didn't
know what it was looking for.
Rod
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
