crypto/testmgr.c | 2 ++ 1 file changed, 2 insertions(+)
If the kernel isn't built with CONFIG_CRYPTO_XXHASH and booted with FIPS
mode enabled it will currently panic. So, only benchmark xxhash64 if
CRYPTO_XXHASH is enabled.
Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com>
Cc: Paul Monson <paul.monson@capgemini.com>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
crypto/testmgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 4985411dedaec..9e4a040029ab8 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5609,7 +5609,9 @@ static const struct alg_test_desc alg_test_descs[] = {
#endif
.alg = "xxhash64",
.test = alg_test_hash,
+#if IS_ENABLED(CONFIG_CRYPTO_XXHASH)
.fips_allowed = 1,
+#endif
.suite = {
.hash = __VECS(xxhash64_tv_template)
}
--
2.53.0
On Tue, Apr 07, 2026 at 12:28:59PM -0700, Hamza Mahfooz wrote: > If the kernel isn't built with CONFIG_CRYPTO_XXHASH and booted with FIPS > mode enabled it will currently panic. So, only benchmark xxhash64 if > CRYPTO_XXHASH is enabled. > > Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com> > Cc: Paul Monson <paul.monson@capgemini.com> > Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> > --- > crypto/testmgr.c | 2 ++ > 1 file changed, 2 insertions(+) Please show me the panic. Normally it's not an issue if an algorithm is not present while the test vectors are. 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
On Wed, Apr 08, 2026 at 04:08:42PM +0800, Herbert Xu wrote: > Please show me the panic. Normally it's not an issue if an algorithm > is not present while the test vectors are. > alg: hash: failed to allocate transform for xxhash64: -2 Kernel panic - not syncing: alg: self-tests for xxhash64 (xxhash64) failed in fips mode! CPU: 0 PID: 425 Comm: modprobe Not tainted 6.6.130.2-2.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 01/08/2026 Call Trace: <TASK> dump_stack_lvl+0x4c/0x70 dump_stack+0x14/0x20 panic+0x179/0x330 alg_test+0x678/0x680 ? __alloc_pages+0x1e2/0x340 do_test+0x26f8/0x7670 [tcrypt] do_test+0x72c5/0x7670 [tcrypt] tcrypt_mod_init+0x65/0xff0 [tcrypt] ? __pfx_tcrypt_mod_init+0x10/0x10 [tcrypt] do_one_initcall+0x4e/0x330 ? kmalloc_trace+0x2e/0xa0 do_init_module+0x68/0x250 load_module+0x1f2e/0x2150 ? __do_sys_init_module+0xe6/0x1d0 __do_sys_init_module+0x19c/0x1d0 ? __do_sys_init_module+0x19c/0x1d0 __x64_sys_init_module+0x1e/0x30 x64_sys_call+0x11b3/0x1c90 do_syscall_64+0x5a/0x80 ? irqentry_exit_to_user_mode+0x29/0x50 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x87/0x160 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7715f70fab9e Code: 48 8b 0d 85 32 12 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 52 32 12 00 f7 d8 64 89 01 48 RSP: 002b:00007ffde8fef6c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 00005d0b39626af0 RCX: 00007715f70fab9e RDX: 00005d0b1710197a RSI: 0000000000028c39 RDI: 00005d0b39635310 RBP: 00005d0b1710197a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000071 R11: 0000000000000246 R12: 00005d0b39635310 R13: 0000000000000000 R14: 00005d0b39626c20 R15: 00005d0b39626da0 </TASK> Seems like crypto_alg_mod_lookup() [1] fails and that triggers the panic() at [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/api.c?h=v7.0-rc7#n338 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/testmgr.c?h=v7.0-rc7#n5760 BR, Hamza
On Thu, Apr 09, 2026 at 10:18:01AM -0700, Hamza Mahfooz wrote: > > alg: hash: failed to allocate transform for xxhash64: -2 > Kernel panic - not syncing: alg: self-tests for xxhash64 (xxhash64) failed in fips mode! > CPU: 0 PID: 425 Comm: modprobe Not tainted 6.6.130.2-2.azl3 #1 > Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 01/08/2026 > Call Trace: > <TASK> > dump_stack_lvl+0x4c/0x70 > dump_stack+0x14/0x20 > panic+0x179/0x330 > alg_test+0x678/0x680 > ? __alloc_pages+0x1e2/0x340 > do_test+0x26f8/0x7670 [tcrypt] So the error is coming from tcrypt. I think that's where the ifdef should be added. 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
On Thu, Apr 16, 2026 at 05:06:27PM +0800, Herbert Xu wrote: > > So the error is coming from tcrypt. I think that's where the ifdef > should be added. On second thought, fips_allowed should not mean that an algorithm must be present. So we should change it such that an -ENOENT is not fatal, or at least when it's called from tcrypt. 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
On Thu, Apr 16, 2026 at 05:09:10PM +0800, Herbert Xu wrote:
> On second thought, fips_allowed should not mean that an algorithm
> must be present.
>
> So we should change it such that an -ENOENT is not fatal, or at least
> when it's called from tcrypt.
>
It appears that commit 6318fbe26e67 ("crypto: testmgr - Hide ENOENT
errors better"), already does exactly that and it appears to resolve the
issue that I'm seeing. So, is there any reason it can't be backported to
stable?
On Fri, Apr 17, 2026 at 10:42:12AM -0700, Hamza Mahfooz wrote:
>
> It appears that commit 6318fbe26e67 ("crypto: testmgr - Hide ENOENT
> errors better"), already does exactly that and it appears to resolve the
> issue that I'm seeing. So, is there any reason it can't be backported to
> stable?
Sure I don't see anything wrong with that.
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
© 2016 - 2026 Red Hat, Inc.