By bug 459248, Linux supports Intel AES-NI. I port it to Windows x64 (MASM).
Created attachment 422661 [details] [diff] [review]
Makoto, can 32-bit support can be added to this patch?
(In reply to comment #2)
> Makoto, can 32-bit support can be added to this patch?
Currently code that is writtern by Ulrich uses XMM8-XMM15, so we has to re-write it to support 32-bit.
Also, this WIP has some bugs, I will fix it when reviewing.
Additional. I am working new fix that is supported x86 and x64 (required VS2008 or later).
Created attachment 535006 [details] [diff] [review]
Created attachment 554787 [details] [diff] [review]
fix v2 [needs work]
If you aren't correct reviewer, who is best?
Brian: are you comfortable with reviewing this, at least as a first pass?
Comment on attachment 554787 [details] [diff] [review]
fix v2 [needs work]
Sorry, it's pretty tricky code with lots of Microsoft specific macros.
With the r+ I'd still like to see the following changes:
1) a comment in front of intel_aes_decrypt_init_192 explaining what is going in with the _mm_aesimc_si128 calls. (what is happening is aes192 keys are 1 1/2 the length of a m128i register, so we need to call store 2/3 of the first key with an _mm_aesimc_si128, then store the remaining 1/2 with a second key giving us 2 full m128i blocks, which we then fixup with later _mm_aesimc calls using xmm2 and xmm4.
2) It's not clear that we won't run out of registers on the 32 bit platforms when we load all the xmm registers up to handle the final partial blocks. My guess is the compiler will handle this, though it might be slower than otherwise. Same comment for the _cbc_encrypt calls. (nothing to do here, just a comment).
3) Right now we have a check for compiler versions in rijndael.c We need the same check intel-aes.c.
4) related to 3, we should probably have an environment variable to turn off hardware accelleration at compile time (that would go in Makefile).
I'd at least like to see #3 addresses, otherwise this won't compile.
On another note, it would be good to make sure we have some Windows test machines with hardware aes support. Any problems will be masked on older hardware as this code is turned off at runtime in those cases.
I'm removing keyword checkin-needed. Based on comment 9 you seem to be requesting a new patch.
needs a new target milestone
Hmm... I didn't know about this bug. In April and May of this year
I reviewed and checked in Intel AES assembly code for Windows from
Shay Gueron of Intel (bug 979703). Using intrinsics seems like a
good idea because they are easier to use than assembly code. But
unless someone is willing to figure out the actual differences
(ignoring intrinsics vs. assembly code) between the two implementations,
I wonder if we should mark this bug WONTFIX now.
*** This bug has been marked as a duplicate of bug 979703 ***