the attached patch adds SHA1 support for VIA PadLock engine.
Did VIA publish documentation for new instructions on their web-site? If not and you have it, can you send a copy to me?
There are several design decisions that I may need to explain: The xsha1 instruction always finalizes the MD computation,
That kind of sucks...
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. What happens when you issue the instruction without rep prefix?
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.
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.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
