Re: [LTP] [PATCH v2 ltp] testcases/kernel/crypto/crypto_user02.c: fix hmac candidate probing

[Eric Biggers via ltp <ltp@lists.linux.it>]

On Thu, Aug 13, 2026 at 05:24:33PM +0200, Frank Ranner wrote:
> Commit a4be708b4 ("try non-generic hmac names first") added a list of
> plain algorithm names (e.g. "hmac(sha256)") that was probed by copying
> each string directly into cru_driver_name, the same way the pre-existing
> "-generic" fallback names were already being probed.
> 
> That approach relies on the newly (or already) registered algorithm's
> actual cra_driver_name being identical to the probed string, which is
> not guaranteed. On current kernels, "hmac(sha256)" is satisfied by a
> non-instance "hmac-sha256-lib" driver matched via the loose cra_name
> fallback in crypto_alg_match(), while template instantiation of "hmac"
> produces driver names such as "hmac-shash(sha256-generic)". Since
> CRYPTO_MSG_DELALG always requires an exact cru_driver_name match, every
> one of the new candidates fails to delete, and setup() silently falls
> through to the legacy "-generic" names, which are themselves absent on
> kernels that dropped the generic hash implementations. The net effect
> is that the test still reports "No viable algorithm found" on affected
> kernels, unchanged from before the commit.
> 
> Fix this by not guessing the driver name at all. Probe each candidate
> by algorithm name (cru_name) instead of driver name, which lets the
> kernel resolve it however it currently does, then use a new
> CRYPTO_MSG_GETALG request to ask the kernel what driver name actually
> satisfies that algorithm. Only that authoritative, kernel-reported
> driver name is used for the deletability check and for the later
> CRYPTO_MSG_DELALG calls in the actual race loop. The race loop's own
> CRYPTO_MSG_NEWALG calls also switch to adding by algorithm name, since
> re-instantiating the same driver on each iteration requires the
> template-parseable "hmac(...)" form rather than its resulting driver
> name.
> 
> This adds tst_crypto_get_alg() to the shared crypto netlink helpers,
> built directly on the existing low-level tst_netlink send/recv
> primitives, so any future crypto test needing to resolve a driver name
> can reuse it instead of re-deriving this logic.
> 
> Verified locally: on a live 7.0 kernel, all of the plain hmac(<hash>)
> candidates for sha1/sha224/sha256/sha384/md5 resolve to permanent
> "-lib"-style drivers and are correctly rejected as non-deletable, while
> hmac(sm3) resolves to a genuine "hmac(sm3-avx)" template instance and
> is correctly selected; the race loop then runs to completion cleanly.
> Rebuilding the pre-fix version of this file on the same kernel confirms
> it falls through every new candidate and only succeeds via the legacy
> "hmac(sm3-generic)" fallback, reproducing the reported failure mode.
> 
> Fixes: c05a44cf ("testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first")
> Signed-off-by: Frank Ranner <frank.ranner@intel.com>

This misses the point of what I said in my last response.  In current
mainline kernels, if you request "hmac(sha256)" you get a
non-template-based algorithm with name="hmac(sha256)",
driver_name="hmac-sha256-lib".  With "hmac(sm3)" you do still usually
get a template-based algorithm, but that's just because the direct
support for HMAC-SM3 hasn't been implemented yet outside of a few random
hardware-specific drivers.  To actually get the template instance now
you would need to request "hmac(sha256-lib)", etc.

At the same time, there's zero reason for userspace to do that other
than verifying that these pointless UAPIs don't cause a kernel crash.
Honestly we should consider just deleting this test, as it is testing
implementation details of legacy stuff that is just causing confusion.

- Eric

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp