BTW, my memory is vague here, is this Padlock block only able to do
one-shot hashing?
Yes, but a technique bypassing this limitation was proposed and proven
to work (as per end of SHA1 thread mentioned earlier). Technique
involved crashing of hashing instruction into non-accessible page. And
that was what I wanted to pursue, but never got time to. Which is why
there was no real follow-up:-( For reference, the plan was to setup
intermediate buffer followed by non-accessible page upon engine setup,
i.e. once, and then serialize access to it with thread synchronizing
primitives. I reckon that serializing threads is OK, because system is
more likely to starve for data than for hashing compute power (1Gbps NIC
vs. ~2Gbps hashing rate).
Strangely enough, I've got uncommitted code to add support for
thread-local-storage ... :-) (It's one of the components in the work I'm
doing for async-crypto.) So if you take the approach you suggesting above, it
should be relatively simple to generalise it later, to avoid
locking/serialisation.
Setting up the intermediate buffer followed by guard page is quite
expensive operation, so you don't want to do it too often. You
definitely don't want to do it upon ->init, and I personally would be
reluctant to do it even on per-thread basis. Being library provider we
don't know how short-lived threads are, and better assume the worst.
Then it might be problematic to clean-up upon thread termination, not to
mention that such buffer is expensive resource by itself. Basically one
has to figure out what impact would serialization have and weigh it
against costs caused by per-thread initialization. But as mentioned, I
think serialization on per-process buffer would be appropriate in this
case. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
