Andy Polyakov wrote:
The xsha1 instruction always finalizes the MD computation,
That kind of sucks...
Hopefully the next version of the CPU will have a new hashing
instruction that will finalize only on request. I was already in touch
with the CPU architects, explained them what problems the current design
brings to us and they agreed to improve it.
i.e. it is
not possible to call the hardware in sha1_update() with the provided
input buffer.
But the instruction with rep prefix is interruptable, i.e. can be
exposed to context switch, right? That would mean that all the
intermediate status has to be kept somewhere, either in visible
registers or off-loaded to memory.
The intermdiate status (and finally the result) is stored in the
128Bytes memory array in padlock_do_sha1(). I.e. it's context switch safe.
What happens when you issue the instruction without rep prefix?
That's invalid instruction I believe.
Instead its necessary to accumulate all data from
update()s in some buffer and hash them only in final().
Note that there is EVP_MD_FLAG_ONESHOT, which can/should be used to
avoid fallback to software at least for such cases.
I have found this flag but didn't realise how to use it. And IIRC it's
only used in one engine. Afterall I decided it's useless and wrote the
software fallback path for SHA.
In padlock_init() I allocate a buffer of a given size (8k as well) whose
first 16B-aligned address goes to buf_start. Having the input data
aligned allows PadLock crunch them faster.
Is 16B-alignment for input a requirement even for SHA? "Even" refers to
AES... A.
No, alignment is required only for output buffer (128 Bytes in
padlock_do_sha1()), but having the input aligned improves performance a
lot. Because we're copying the data anyway, we can copy it to an aligned
address.
BTW In VIA Esther the buffers for AES can be unaligned in some cases as
well. I'll come up with a patch.
Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
