On 02/10/2025 12:57, Jiri Slaby wrote:

On 02. 10. 25, 12:13, Jiri Slaby wrote:

quoted

On 02. 10. 25, 12:05, Jiri Slaby wrote:

quoted

On 02. 10. 25, 11:30, Herbert Xu wrote:

quoted

On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:

quoted

On 29. 07. 25, 13:07, Herbert Xu wrote:

quoted

Vegard Nossum (1):
        crypto: testmgr - desupport SHA-1 for FIPS 140

Booting 6.17 with fips=1 crashes with this commit -- see below.

The crash is different being on 6.17 (below) and on the commit --
9d50a25eeb05c45fef46120f4527885a14c84fb2.

6.17 minus that one makes it work again.

Any ideas?

The purpose of the above commit is to remove the SHA1 algorithm
if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
sha1 algorithm, it will obviously fail if SHA1 isn't there.

Ok, but I don't immediately see what is one supposed to do to boot 
6.17 distro (openSUSE) kernel with fips=1 then?

First off, I just want to acknowledge that my commit to disable SHA-1
when booting with fips=1 is technically regressing userspace as well as
this specific ipv6 code.

However, fips=1 has a very specific use case, which is FIPS compliance.
Now, SHA-1 has been deprecated since 2011 but not yet fully retired
until 2030.

The purpose of the commit is to actually begin the transition as is
encouraged by NIST and prevent any new FIPS certifications from expiring
early, which would be the outcome for any FIPS certifications initiated
after December 31 this year. I think this is in line with the spirit of
using and supporting fips=1 to begin with, in the sense that if you
don't care about using SHA-1 then you probably don't care about fips=1
to start with either.

If you really want to continue using SHA-1 in FIPS mode with 6.17 then I
would suggest reverting my patch downstream as the straightforward fix.

quoted

Now I do, in the context you write, I see inet6_init()'s fail path is 
broken. The two backtraces show:
[    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
[    2.382321][    T1]  inet6_init+0x365/0x3d0

and

[    2.420857][    T1]  proto_unregister+0x93/0x100
[    2.420857][    T1]  inet6_init+0x3a2/0x3d0

I am looking what exactly, but this is rather for netdev@

More functions from the fail path are not ready to unroll and resurrect 
from the failure.

Anyway, cherry-picking this -next commit onto 6.17 works as well (the 
code uses now crypto_lib's sha1, not crypto's):
commit 095928e7d80186c524013a5b5d54889fa2ec1eaa
Author: Eric Biggers [off-list ref]
Date:   Sat Aug 23 21:36:43 2025 -0400

     ipv6: sr: Use HMAC-SHA1 and HMAC-SHA256 library functions


I don't know what to do next -- should it be put into 6.17 stable later 
and we are done?

I'd like to raise a general question about FIPS compliance here,
especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
made available outside of the crypto API and code around the kernel is
making direct use of it, then this seems to completely subvert the
purpose of CONFIG_CRYPTO_FIPS/fips=1 since it essentially makes the
kernel non-compliant even when booting with fips=1.

Is this expected? Should it be documented?

FIPS also has a bunch of requirements around algorithm testing, for
example that every algorithm shall pass tests before it can be used.
lib/crypto/ has kunit tests, but there is no interaction with
CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
mechanism. This seems like a bad thing for all the distros that are
currently certifying their kernels for FIPS.


Vegard