CI: Another strange crypto message in syslog

CI: Another strange crypto message in syslog

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

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

-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
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/

Re: CI: Another strange crypto message in syslog

[Eric Biggers]

On Thu, Jun 05, 2025 at 01:26:34PM +0200, Ingo Franzki wrote:
> 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 <herbert@gondor.apana.org.au>
    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.

> 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/20250419161543.139344-4-ebiggers@kernel.org/,
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

Re: CI: Another strange crypto message in syslog

[Harald Freudenberger]

On 2025-06-05 16:26, Eric Biggers wrote:
> On Thu, Jun 05, 2025 at 01:26:34PM +0200, Ingo Franzki wrote:
>> 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 <herbert@gondor.apana.org.au>
>     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.
> 
>> 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/20250419161543.139344-4-ebiggers@kernel.org/,
> 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

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.

Re: CI: Another strange crypto message in syslog

[Eric Biggers]

On Fri, Jun 06, 2025 at 09:19:18AM +0200, Harald Freudenberger wrote:
> > 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/20250419161543.139344-4-ebiggers@kernel.org/,
> > 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
> 
> 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.

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

Re: CI: Another strange crypto message in syslog

[Harald Freudenberger]

On 2025-06-06 19:45, Eric Biggers wrote:
> On Fri, Jun 06, 2025 at 09:19:18AM +0200, Harald Freudenberger wrote:
>> > 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/20250419161543.139344-4-ebiggers@kernel.org/,
>> > 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
>> 
>> 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.
> 
> 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

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

Re: CI: Another strange crypto message in syslog

[Eric Biggers]

On Mon, Jun 16, 2025 at 12:50:07PM +0200, Harald Freudenberger wrote:
> On 2025-06-06 19:45, Eric Biggers wrote:
> > On Fri, Jun 06, 2025 at 09:19:18AM +0200, Harald Freudenberger wrote:
> > > > 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/20250419161543.139344-4-ebiggers@kernel.org/,
> > > > 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
> > > 
> > > 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.
> > 
> > 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
> 
> 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

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/20250612174709.26990-1-ebiggers@kernel.org/

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

Re: CI: Another strange crypto message in syslog

[Ingo Franzki]

On 05.06.2025 16:26, Eric Biggers wrote:
> No, it's from the following commit:
> 
>     commit ef93f1562803cd7bb8159e3abedaf7f47dce4e35
>     Author: Herbert Xu <herbert@gondor.apana.org.au>
>     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.

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.

-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
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] crypto: hkdf - move to late_initcall

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

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.

Fixes: ef93f1562803 ("Revert "crypto: run initcalls for generic implementations earlier"")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/hkdf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/hkdf.c b/crypto/hkdf.c
index f24c2a8d4df99..82d1b32ca6ce4 100644
--- a/crypto/hkdf.c
+++ b/crypto/hkdf.c
@@ -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
-- 
2.49.0

Re: [PATCH] crypto: hkdf - move to late_initcall

[Herbert Xu]

On Tue, Jun 10, 2025 at 12:16:00PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> 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.
> 
> Fixes: ef93f1562803 ("Revert "crypto: run initcalls for generic implementations earlier"")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  crypto/hkdf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt