On Wed, 2008-12-10 at 03:40 +0800, Andy Polyakov wrote: > As for RFC part. NO! This is NOT the way to do it. For several reasons > (in ascending order of importance): > > - OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable > for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI issue. > - "and $-16, %rdx" is unacceptable in this context. The relevant > interface is exposed to end-user and we have to reserve for possibility > that key schedule is memcpy-ed to location with alternative alignment; Does there any other mechanism to deal with alignment issue in OpenSSL? Is it better to declare AES_KEY as follow: struct aes_key_st { unsigned int rd_key[4 *(AES_MAXNR + 1)]; int rounds; } __attribute__ ((aligned (16))); And how to deal with memory allocated with malloc()? > - zero-copy CBC routine gives a fair performance improvement even in > ordinary case, and driving ultra-fast block function from C would be > just wasteful. In other words AESENC/DEC would benefit more from > dedicated CBC routine (see even comment below); I will do more investigation on that. > - implementation should allow for pipelining; > > As for the latter. I refer to possibility of scheduling of multiple > AESENC/DEC with same key schedule element and multiple data chunks. It's > possible in modes that allow for parallelization (e.g. ECB, CBC decrypt, > CTR), and as far as I understand it is even recommended. So we are kind > of obliged to reserve for this option. > > The answer is engine. I mean this preferably should be implemented as > engine that will be able to take full advantage of architecture, not as > patch to general purpose block function. But as Peter Waltenberg said, engine has its issue too. At least we should have a "branch" based version (may be slower) to benefit most users, until we can make engine version usable by most users. > > This patch adds support to Intel AES-NI instruction set for x86_64 > > platform. > > > > Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD) > > instructions that are going to be introduced in the next generation of > > Intel processor, as of 2009. > > Hardware however is not expected before 2010, right? A. Maybe 2009 or 2010, I don't know that exactly too. Best Regards, Huang Ying
signature.asc
Description: This is a digitally signed message part