CI: Another strange crypto message in syslog
Hi Herbert,
we see the following error messages in syslog on the current next kernel:
Jun 05 13:15:20 a35lp62.lnxne.boe kernel: basic hdkf test(hmac(sha256)): failed to allocate transform: -2 Jun 05 13:15:20 a35lp62.lnxne.boe kernel: alg: full crypto tests enabled. This is intended for developer use only.
The first one seem to be failure, but I can't tell where..... I don't see any other typical selftest failure messages. -1 is ENOENT. It might be related to the recent changes with sha256 being now in a library...
The second one is probably because the full selftests are now enabled by default. Does it make sense to output this message now anymore at all?
Kind regards,
Ingo
Signature · 10 lines
Ingo Franzki eMail: [email protected] Tel: ++49 (0)7031-16-4648 Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
Quoted 9 lines · Ingo Franzki
Hi Herbert,
we see the following error messages in syslog on the current next kernel:
Jun 05 13:15:20 a35lp62.lnxne.boe kernel: basic hdkf test(hmac(sha256)): failed to allocate transform: -2 Jun 05 13:15:20 a35lp62.lnxne.boe kernel: alg: full crypto tests enabled. This is intended for developer use only.The first one seem to be failure, but I can't tell where..... I don't see any other typical selftest failure messages. -1 is ENOENT. It might be related to the recent changes with sha256 being now in a library...
No, it's from the following commit:
commit ef93f1562803cd7bb8159e3abedaf7f47dce4e35
Author: Herbert Xu <[email protected]>
Date: Wed Apr 30 16:17:02 2025 +0800
Revert "crypto: run initcalls for generic implementations earlier"
That moved the crypto_shash support for hmac and sha256 from subsys_initcall to module_init, which put at the same level as crypto_hkdf_module_init which depends on it.
I guess we just move crypto_hkdf_module_init to late_initcall for now.
Quoted 2 lines
The second one is probably because the full selftests are now enabled by default. Does it make sense to output this message now anymore at all?
The crypto self-tests remain disabled by default; there's just no longer a difference between the "regular tests" and the "full tests". The warning makes sense to me. There should be an indication that the tests are running since they take a long time and should not be enabled in production kernels.
If this is s390, arch/s390/configs/defconfig has CONFIG_CRYPTO_SELFTESTS=y. Is that really what you want? I tried to remove it as part of
https://lore.kernel.org/linux-crypto/[email protected]/,
but someone complained about that patch so I ended up dropping it. But maybe you still want to remove it from arch/s390/configs/defconfig. There's already arch/s390/configs/debug_defconfig that has it enabled too, and maybe you only want tests enabled in the "debug" one?
- Eric
Quoted 43 lines · Eric Biggers
Quoted 10 lines · Ingo Franzki
Hi Herbert,
we see the following error messages in syslog on the current next kernel:
Jun 05 13:15:20 a35lp62.lnxne.boe kernel: basic hdkf test(hmac(sha256)): failed to allocate transform: -2 Jun 05 13:15:20 a35lp62.lnxne.boe kernel: alg: full crypto tests enabled. This is intended for developer use only.The first one seem to be failure, but I can't tell where..... I don't see any other typical selftest failure messages. -1 is ENOENT. It might be related to the recent changes with sha256
being now in a library...No, it's from the following commit:
commit
ef93f1562803cd7bb8159e3abedaf7f47dce4e35
Author: Herbert Xu <[email protected]>
Date: Wed Apr 30 16:17:02 2025 +0800Revert "crypto: run initcalls for generic implementations
earlier"That moved the
crypto_shashsupport for hmac and sha256 fromsubsys_initcalltomodule_init, which put at the same level ascrypto_hkdf_module_initwhich depends on it.I guess we just move
crypto_hkdf_module_inittolate_initcallfor now.Quoted 2 lines
The second one is probably because the full selftests are now enabled by default. Does it make sense to output this message now anymore at all?
The crypto self-tests remain disabled by default; there's just no longer a difference between the "regular tests" and the "full tests". The warning makes sense to me. There should be an indication that the tests are running since they take a long time and should not be enabled in production kernels.
If this is s390,
arch/s390/configs/defconfighasCONFIG_CRYPTO_SELFTESTS=y. Is that really what you want? I tried to remove it as part of
https://lore.kernel.org/linux-crypto/[email protected]/,
but someone complained about that patch so I ended up dropping it. But maybe you still want to remove it fromarch/s390/configs/defconfig. There's alreadyarch/s390/configs/debug_defconfigthat has it enabled too, and maybe you only want tests enabled in the "debug" one?
Quoted 1 line
- Eric
Looks like we have no other options than disabling the selftests in defconfig. We have debug_defconfig - with all the now huge set of test running in CI. But for my feeling it was making total sense to have a subset of the tests run with registration of each crypto algorithm even in production kernels. However, as wrote ... there is no choice anymore.
Quoted 20 lines · Harald Freudenberger
Quoted 20 lines
The crypto self-tests remain disabled by default; there's just no longer a
difference between the "regular tests" and the "full tests". The warning makes
sense to me. There should be an indication that the tests are running since
they take a long time and should not be enabled in production kernels.If this is s390,
arch/s390/configs/defconfighasCONFIG_CRYPTO_SELFTESTS=y. Is
that really what you want? I tried to remove it as part of
https://lore.kernel.org/linux-crypto/[email protected]/,
but someone complained about that patch so I ended up dropping it. But maybe
you still want to remove it fromarch/s390/configs/defconfig. There's alreadyarch/s390/configs/debug_defconfigthat has it enabled too, and maybe you only
want tests enabled in the "debug" one?
Quoted 8 lines
Quoted 1 line
- Eric
Looks like we have no other options than disabling the selftests in defconfig.
We havedebug_defconfig- with all the now huge set of test running in CI. But for my feeling it was making total sense to have a subset of the tests run with registration of each crypto algorithm even in production kernels. However, as wrote ... there is no choice anymore.
There's still a command-line option cryptomgr.noslowtests=1.
If you really want it, we could add back a kconfig option to control whether the self-tests run the "fast" tests only or not. I thought that the only use case for running the "fast" tests only was for people who are misusing these tests for FIPS pre-operational self-testing. (Which has always been a poor match, as FIPS requires only a single test of any length per algorithm, for only a subset of algorithms. It's totally different from actually doing proper testing.) Those people should be okay with the command-line option.
I do think the idea of running the tests in production kernels is questionable. There are enough tests now that you can't run all of them (and indeed you are not asking for that), which means the production testing will be incomplete, and the real testing needs to be done in the development phase with a build that has the tests enabled anyway. The same applies to other kernel subsystems too.
- Eric
Quoted 40 lines · Eric Biggers
Quoted 20 lines · Harald Freudenberger
Quoted 20 lines
The crypto self-tests remain disabled by default; there's just no longer a
difference between the "regular tests" and the "full tests". The warning makes
sense to me. There should be an indication that the tests are running since
they take a long time and should not be enabled in production kernels.If this is s390,
arch/s390/configs/defconfighasCONFIG_CRYPTO_SELFTESTS=y. Is
that really what you want? I tried to remove it as part of
https://lore.kernel.org/linux-crypto/[email protected]/,
but someone complained about that patch so I ended up dropping it. But maybe
you still want to remove it fromarch/s390/configs/defconfig. There's alreadyarch/s390/configs/debug_defconfigthat has it enabled too, and maybe you only
want tests enabled in the "debug" one?Quoted 8 lines
Quoted 1 line
- Eric
Looks like we have no other options than disabling the selftests in defconfig.
We havedebug_defconfig- with all the now huge set of test running in CI. But for my feeling it was making total sense to have a subset of the tests run with registration of each crypto algorithm even in production kernels. However, as wrote ... there is no choice anymore.There's still a command-line option cryptomgr.noslowtests=1.
If you really want it, we could add back a kconfig option to control whether the self-tests run the "fast" tests only or not. I thought that the only use case for running the "fast" tests only was for people who are misusing these tests for FIPS pre-operational self-testing. (Which has always been a poor match, as FIPS requires only a single test of any length per algorithm, for only a subset of algorithms. It's totally different from actually doing proper testing.) Those people should be okay with the command-line option.
Quoted 7 lines
I do think the idea of running the tests in production kernels is questionable. There are enough tests now that you can't run all of them (and indeed you are not asking for that), which means the production testing will be incomplete, and the real testing needs to be done in the development phase with a build that has the tests enabled anyway. The same applies to other kernel subsystems too.
- Eric
In general I agree to this. Clearly it makes no sense to run all
the tests all time when a new algorithm is registered.
The thing is ... everybody wants to test as close as possible to the production systems. So the kernels are usually build for production - now without any selftests. But all the Linux distributors happily patch whatever they think is necessary and build production kernels - now without any in-kernel crypto selftests. The only places where selftests are now executed is in 'special' environments like CIs or on development systems and hopefully findings there are handled seriously by the maintainers and developers.
Harald Freudenberger
Quoted 75 lines · Harald Freudenberger
Quoted 60 lines · Eric Biggers
Quoted 22 lines · Harald Freudenberger
Quoted 20 lines
The crypto self-tests remain disabled by default; there's just no longer a
difference between the "regular tests" and the "full tests". The warning makes
sense to me. There should be an indication that the tests are running since
they take a long time and should not be enabled in production kernels.If this is s390,
arch/s390/configs/defconfighasCONFIG_CRYPTO_SELFTESTS=y. Is
that really what you want? I tried to remove it as part of
https://lore.kernel.org/linux-crypto/[email protected]/,
but someone complained about that patch so I ended up dropping it. But maybe
you still want to remove it fromarch/s390/configs/defconfig. There's alreadyarch/s390/configs/debug_defconfigthat has it enabled too, and maybe you only
want tests enabled in the "debug" one?Quoted 1 line
- Eric
Quoted 9 lines
Looks like we have no other options than disabling the selftests in defconfig.
We havedebug_defconfig- with all the now huge set of test running in CI.
But for my feeling it was making total sense to have a subset of the tests
run with registration of each crypto algorithm even in production kernels.
However, as wrote ... there is no choice anymore.There's still a command-line option cryptomgr.noslowtests=1.
If you really want it, we could add back a kconfig option to control whether the
self-tests run the "fast" tests only or not. I thought that the only use case
for running the "fast" tests only was for people who are misusing these tests
for FIPS pre-operational self-testing. (Which has always been a poor match, as
FIPS requires only a single test of any length per algorithm, for only a subset
of algorithms. It's totally different from actually doing proper testing.)
Those people should be okay with the command-line option.I do think the idea of running the tests in production kernels is questionable.
There are enough tests now that you can't run all of them (and indeed you are
not asking for that), which means the production testing will be incomplete, and
the real testing needs to be done in the development phase with a build that has
the tests enabled anyway. The same applies to other kernel subsystems too.Quoted 1 line
- Eric
In general I agree to this. Clearly it makes no sense to run all the tests all time when a new algorithm is registered.
The thing is ... everybody wants to test as close as possible to the production systems. So the kernels are usually build for production - now without
any selftests. But all the Linux distributors happily patch whatever they think
is necessary and build production kernels - now without any in-kernel crypto selftests. The only places where selftests are now executed is in 'special' environments like CIs or on development systems and hopefully findings there are handled seriously by the maintainers and developers.
Quoted 1 line
Harald Freudenberger
FYI: due to all the buggy hardware drivers and distros wanting to enable the crypto self-tests in production, we did decide to restore the ability to run only the "fast" crypto self-tests. See:
https://lore.kernel.org/r/[email protected]/
The full tests will once again not be enabled in any of the defconfigs. You may want to enable CRYPTO_SELFTESTS_FULL in arch/s390/configs/debug_defconfig.
- Eric
Quoted 6 lines · Eric Biggers
No, it's from the following commit:
commit
ef93f1562803cd7bb8159e3abedaf7f47dce4e35
Author: Herbert Xu <[email protected]>
Date: Wed Apr 30 16:17:02 2025 +0800
Quoted 7 lines
Revert "crypto: run initcalls for generic implementations earlier"
That moved the
crypto_shashsupport for hmac and sha256 fromsubsys_initcalltomodule_init, which put at the same level ascrypto_hkdf_module_initwhich depends on it.I guess we just move
crypto_hkdf_module_inittolate_initcallfor now.
It still fails the same way in a current next kernel. Will there be a fix for it any time soon?
BTW: I guess there is a typo:
"basic hdkf test(hmac(sha256)): failed to allocate transform: -2"
should probably read:
"basic hkdf ..."
All the code around this string is about HKDF (HMAC Key Derivation Function), not HDKF.
Signature · 10 lines
Ingo Franzki eMail: [email protected] Tel: ++49 (0)7031-16-4648 Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
PATCH 1/1 crypto: hkdf - move to late_initcall
From: Eric Biggers <[email protected]>
The HKDF self-tests depend on the HMAC algorithms being registered. HMAC is now registered at module_init, which put it at the same level as HKDF. Move HKDF to late_initcall so that it runs afterwards.
--- crypto/hkdf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/hkdf.c +1 -1
@@ -564,10 +564,10 @@ static int __init crypto_hkdf_module_init(void)return 0 ; } static void __exit crypto_hkdf_module_exit(void) {} -module_init (crypto_hkdf_module_init); +late_initcall (crypto_hkdf_module_init);module_exit (crypto_hkdf_module_exit);MODULE_LICENSE ("GPL" );MODULE_DESCRIPTION ("HMAC-based Key Derivation Function (HKDF)" );
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
Signature · 1 line
2.49.0
Herbert Xu
maintainerRe: [PATCH] crypto: hkdf - move to late_initcall
Quoted 11 lines · Eric Biggers
From: Eric Biggers <[email protected]>
The HKDF self-tests depend on the HMAC algorithms being registered. HMAC is now registered at
module_init, which put it at the same level as HKDF. Move HKDF tolate_initcallso that it runs afterwards.Fixes ef93f1562803 ("Revert "crypto: run initcalls for generic implementations earlier"")Signed-off-by Eric Biggers <[email protected]>--- crypto/hkdf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt