[LTP] [PATCH ltp] testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first

[LTP] [PATCH ltp] testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first

[Frank Ranner]

Probe plain hmac(<hash>) driver names before the legacy *-generic
variants when selecting a viable algorithm for crypto_user02.

Newer kernels commonly expose non-generic algorithm names while
no longer registering the *-generic aliases, which made the current
candidate list fall through to TCONF even when usable algorithms
were present.

Keeping both forms preserves compatibility with older kernels while
avoiding kernel-version checks in the testcase logic.

Signed-off-by: Frank Ranner <frank.ranner@intel.com>
---
 testcases/kernel/crypto/crypto_user02.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/testcases/kernel/crypto/crypto_user02.c b/testcases/kernel/crypto/crypto_user02.c
index 88ae800aa..c08d35c84 100644
--- a/testcases/kernel/crypto/crypto_user02.c
+++ b/testcases/kernel/crypto/crypto_user02.c
@@ -35,6 +35,20 @@
  * The first algorithm, that fullfils the criteria is used for the test.
  */
 static const char * const ALGORITHM_CANDIDATES[] = {
+	"hmac(sha1)",
+	"hmac(sha224)",
+	"hmac(sha256)",
+	"hmac(sha384)",
+	"hmac(md5)",
+	"hmac(sm3)",
+	"hmac(sha512)",
+	"hmac(rmd160)",
+	"hmac(sha3-224)",
+	"hmac(sha3-256)",
+	"hmac(sha3-384)",
+	"hmac(sha3-512)",
+	"hmac(streebog256)",
+	"hmac(streebog512)",
 	"hmac(sha1-generic)",
 	"hmac(sha224-generic)",
 	"hmac(sha256-generic)",
-- 
2.53.0

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


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

Re: [LTP] testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first

[linuxtestproject.agent]

Hi Frank,

On Wed, 12 Aug 2026, Frank Ranner wrote:
> testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first

> +	"hmac(sha1)",
> +	"hmac(sha224)",
> +	"hmac(sha256)",
> +	"hmac(sha384)",
> +	"hmac(md5)",
> +	"hmac(sm3)",
> +	"hmac(sha512)",
> +	"hmac(rmd160)",
> +	"hmac(sha3-224)",
> +	"hmac(sha3-256)",
> +	"hmac(sha3-384)",
> +	"hmac(sha3-512)",
> +	"hmac(streebog256)",
> +	"hmac(streebog512)",

[Major] Could these be replaced with actual deletable instance driver names?
The strings are copied into cru_driver_name, but these new values are
algorithm names.

On Linux 7.2, CRYPTO_MSG_NEWALG first misses the exact driver-name lookup
for "hmac(sha256)", then finds the non-instance "hmac-sha256-lib" driver by
its cra_name and returns success. CRYPTO_MSG_DELALG subsequently requires an
exact driver-name match, cannot find "hmac(sha256)", and returns ENOENT.

Consequently, the setup loop rejects every newly added candidate and still
reaches TCONF when the legacy *-generic instances are absent. The 7.2 HMAC
shash template instead produces deletable hmac-shash(<driver>) instance
names.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

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

Re: [LTP] [PATCH ltp] testcases/kernel/crypto/crypto_user02.c: try non-generic hmac names first

[Eric Biggers via ltp]

On Wed, Aug 12, 2026 at 01:27:37PM +0200, Frank Ranner wrote:
> Probe plain hmac(<hash>) driver names before the legacy *-generic
> variants when selecting a viable algorithm for crypto_user02.
> 
> Newer kernels commonly expose non-generic algorithm names while
> no longer registering the *-generic aliases, which made the current
> candidate list fall through to TCONF even when usable algorithms
> were present.
> 
> Keeping both forms preserves compatibility with older kernels while
> avoiding kernel-version checks in the testcase logic.
> 
> Signed-off-by: Frank Ranner <frank.ranner@intel.com>
> ---
>  testcases/kernel/crypto/crypto_user02.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/testcases/kernel/crypto/crypto_user02.c b/testcases/kernel/crypto/crypto_user02.c
> index 88ae800aa..c08d35c84 100644
> --- a/testcases/kernel/crypto/crypto_user02.c
> +++ b/testcases/kernel/crypto/crypto_user02.c
> @@ -35,6 +35,20 @@
>   * The first algorithm, that fullfils the criteria is used for the test.
>   */
>  static const char * const ALGORITHM_CANDIDATES[] = {
> +	"hmac(sha1)",
> +	"hmac(sha224)",
> +	"hmac(sha256)",
> +	"hmac(sha384)",
> +	"hmac(md5)",
> +	"hmac(sm3)",
> +	"hmac(sha512)",
> +	"hmac(rmd160)",
> +	"hmac(sha3-224)",
> +	"hmac(sha3-256)",
> +	"hmac(sha3-384)",
> +	"hmac(sha3-512)",
> +	"hmac(streebog256)",
> +	"hmac(streebog512)",
>  	"hmac(sha1-generic)",
>  	"hmac(sha224-generic)",
>  	"hmac(sha256-generic)",

This kind of defeats the point of the test, as the hmac template will no
longer be tested; the kernel now implements the stable names
"hmac(sha1)", "hmac(sha256)", etc. directly without the fragile template
system.  The test is specifically checking for a crash when deleting a
template instance.  I guess use the new driver names generated by the
template to force its use: "hmac(sha1-lib)", "hmac(sha256-lib)", etc.  

Not like this UAPI has any point in the first place.  But as long as
this test still exists and is trying to test for this historical bug, we
might as well preserve the intent.

(It's also strange that so many algorithms are listed, when just one
actually ends up being used.  But that is a separate issue.)

- Eric

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