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 <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
