Rod, I've never experienced myself, so its a problem I have not had to tackle. I've always looked at that from the config.h and CRYPTOPP_DISABLE_AESNI side of things (https://svn.code.sf.net/p/cryptopp/code/trunk/c5/config.h).
But I think you are right. There's an opportunity for improvement there. I think there are two issues: use of the Double Quad Word Multiply instruction, and use of the AES-NI instructions. As I understand it, they are different features (please correct me here), and grouping them together may not be a good strategy. And of course, the issue of runtime detection you pointed out. Jeff On Mon, Dec 29, 2014 at 5:15 PM, Rod <[email protected]> wrote: > 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.
