Re: [PATCH v5 04/19] crypto: cmh - add SHA-2/SHA-3/SHAKE ahash

[Herbert Xu <herbert@gondor.apana.org.au>]

On Wed, Sep 23, 2026 at 08:50:55PM +0000, Ousherovitch, Alex wrote:
>
> - shake128/256, cshake, kmac and poly1305 have no matching provider
>   registered in this tree, so the allocation fails and the transform can't
>   be created at all. NO_FALLBACK is required to instantiate them.

Hang on, if an algorithm isn't even implemented in generic C for
the Crypto API, then it should not be implemented by a driver
either.

The reason these algorithms aren't in the Crypto API is because
they have no users.

So please drop them.

> - sha2, sha3 and sm3 do have a software provider, so the transform loads,
>   but the auto-fallback can't stand in for the hardware on the streaming
>   path: our exported state is the opaque HW save/restore checkpoint, not
>   the canonical state, so a multi-part export/import round-trip through the
>   fallback misinterprets it (and for SHA-2/SHA-3 the statesize exceeds
>   HASH_MAX_STATESIZE, so ahash_do_req_chain() returns -ENOSYS). A one-shot
>   digest could still use the software provider, but a fallback that only
>   covers one-shot and corrupts streaming isn't usable.

Sorry, that is not supported by our API.  If you cannot export the
hash state in a compatible format, then you will have to switch over
to fallbacks and only support digest operations.

Please also elaborate what you mean by opaque checkpoint, does it
contain the entire hash state or not?

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