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

[Ousherovitch, Alex]

On Wed, Sep 23, 2026 at 03:47:41PM +1000, Herbert Xu wrote:
> Why did you set the NO_FALLBACK flag? This is only meant to be used
> by very specific cases such as s390.

Being async, these algs get NEED_FALLBACK forced by ahash_prepare_alg()
unless NO_FALLBACK is set, so crypto_ahash_init_tfm() tries to allocate a
same-name synchronous REQ_VIRT provider -- which doesn't work here:

- 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.

- 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.

Same flag as s390, same underlying reason -- no generic transform can stand
in for the hardware -- though the obstruction differs: protected keys
there, opaque (and for SHA-2/SHA-3 oversized) HW state here.

Thanks,
Alex