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

[Ousherovitch, Alex]

On Mon, Oct 05, 2026 at 05:04:25PM +0000, Ousherovitch, Alex wrote:
> For the algorithms that have a generic provider -- SHA-2,
> SHA-3, SM3, HMAC(SHA-2/SHA-3), CMAC(AES), CMAC(SM4) and XCBC(SM4) --
> v6 switches to the fallback/digest-only model:
>
>   - drop the NO_FALLBACK / BLOCK_ONLY / REQ_VIRT flags [...]
>
> That also answers your NO_FALLBACK question: the flag is gone.

One correction to the above before I post v6, so it doesn't look like a
quiet regression in the patches: that holds for SHA-2, SHA-3, SM3 and
HMAC, but not for CMAC(AES), CMAC(SM4) and XCBC(SM4) -- those three keep
NO_FALLBACK and REQ_VIRT.

The reason is the generic fallback itself. crypto/cmac.c and
crypto/xcbc.c implement only descsize, with no export_core/import_core,
so the core marks them NO_EXPORT_CORE and crypto_ahash_init_tfm() cannot
wrap them as crypto_ahash_fb() -- that allocation carries the bit in its
mask and fails. For an async digest-only MAC that leaves no choice:
ahash_prepare_alg() forces NEED_FALLBACK unless NO_FALLBACK is set, and
the fallback it would otherwise build is unallocatable here. So these
three set NO_FALLBACK, keep REQ_VIRT, and allocate the same generic
cmac/xcbc transform themselves to service the non-digest paths.

Behaviorally they match the hashes -- hardware .digest() only, with
.init/.update/.final/.export/.import forwarded to the generic transform
(crypto_ahash_fb() where the core provides it, a driver-allocated one for
these three) and the virtual-address path in software; only the flag
differs. HMAC does not hit this because crypto/hmac.c provides
export_core/import_core. BLOCK_ONLY is gone everywhere, as described, and
the rest of that message stands.

If you'd rather these three didn't carry the flag, I can drop cmac(aes),
cmac(sm4) and xcbc(sm4) from the driver instead.

Thanks,
Alex