Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> Linux actually used to support SHA-256 multibuffer hashing on x86_64,
> before it was removed by commit ab8085c130ed ("crypto: x86 - remove SHA
> multibuffer routines and mcryptd"). However, it was integrated with the
> crypto API in a weird way, where it behaved as an asynchronous hash that
> queued up and executed all requests on a global queue. This made it
> very complex, buggy, and virtually unusable.
>
> This patch takes a new approach of just adding an API
> crypto_shash_finup_mb() that synchronously computes the hash of multiple
> equal-length messages, starting from a common state that represents the
> (possibly empty) common prefix shared by the messages.
I absolutely love the multi-buffer idea that you've come up with.
But (as you know) I dislike the shash implementation.
I'm almost there with the ahash version of this, there's just a few
corner cases I need to cover due to the addition of virt address
support to ahash. Incidentally this also means that I'm going to
scrap lskcipher and redo it as a normal skcipher with virt address
support.
BTW, I just discovered a new application for this. The marvell/cesa
driver wants to chain multiple hash requests together to reduce IRQs
and improve efficiency. It was doing some ad-hoc (and possibly buggy)
chaining in its queueing code to achieve this.
I think having a chained submission interface solves this in a much
nicer way. The driver could then simply pick up a submission chain,
transform it, and then feed it directly to the hardware.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
