I hope I addressed all your wishes w.r.t. the PadLock engine. Attached is the interdiff since the last version, on my PadLock page is the full patch (http://www.logix.cz/michal/devel/padlock).
Do you now like it more? :-)
I hope that you don't really think that it's matter of *liking*:-)
Problem.
... padlock_aes_cipher(... const uint8_t *in_arg,...)
{ ...
if (in_arg_aligned) {
in = (uint8_t*)in_arg;
if (out_arg_aligned)
out = out_arg;
else
out = in;Last line is no good. in_arg is declared const and is not expected to be modified. This is of course unfortunate, but you can't take advantage of the fact that input buffer happens to be aligned.
Further comments.
Throw in pushfl;popfl; at the end of padlock_aes_init_key. This would be required if we try to optimize pushfl;popfl; in padlock_aes_cipher, but we can as well do it now.
Have you considered to rearrange switch and loop in padlock_aes_cipher? I mean right now you have switch in loop, while you could have loop for every case in switch. It might make difference to performance...
Can you explain what's the deal with IV? I don't quite undestand why do you save EAX value after xscrypt and use at as a pointer. Where does it point at exit? The way I understand the manual you simply can't rely on value in EAX being preseved and I can't see that it's meaningful after xcrypt...
What's padlock_cipher_data->key for? It only pollutes the cache... You can as well padlock_cipher_data->ks.rd_key, can't you? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
