Re: [PATCH v8 0/7] Optimize dm-verity and fsverity using multibuffer hashing

From: Herbert Xu
Date: Thu Feb 13 2025 - 22:51:19 EST


On Thu, Feb 13, 2025 at 07:35:18PM -0800, Eric Biggers wrote:
>
> It absolutely is designed for an obsolete form of hardware offload. Have you
> ever tried actually using it? Here's how to hash a buffer of data with shash:
>
> return crypto_shash_tfm_digest(tfm, data, size, out)
>
> ... and here's how to do it with the SHA-256 library, for what it's worth:
>
> sha256(data, size, out)
>
> and here's how to do it with ahash:

Try the new virt ahash interface, and we could easily put the
request object on the stack for sync algorithms:

SYNC_AHASH_REQUEST_ON_STACK(req, alg);

ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
ahash_request_set_virt(req, data, out, size);

return crypto_ahash_digest(req);

> Hmm, I wonder which API users would rather use?

You're conflating the SG API problem with the interface itself.
It's a separate issue, and quite easily solved.

> What? GHASH is a polynomial hash function, so it is easily parallelizable. If
> you precompute N powers of the hash key then you can process N blocks in
> parallel. Check how the AES-GCM assembly code works; that's exactly what it
> does. This is fundamentally different from message digests like SHA-* where the
> blocks have to be processed serially.

Fair enough.

But there are plenty of other users who want batching, such as the
zcomp with iaa, and I don't want everybody to invent their own API
for the same thing.

Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt