Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:

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

quoted

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

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

lib/ has had SHA-1 support since 2005.  The recent changes just made the
SHA-1 API more comprehensive and more widely used in the kernel.

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?

If calling code would like to choose not to use or allow a particular
crypto algorithm when fips_enabled=1, it's free to do so.  

That's far more flexible than the crypto/ approach, which has
historically been problematic since it breaks things unnecessarily.  The
caller can actually do something that makes sense for it, including:

- Deciding whether FIPS requirements even apply to it in the first
  place.  (Considering that it may or may not be implementing something
  that would be considered a "security function" by FIPS.)

- Targeting the disablement to the correct, narrow area.  (Not something
  overly-broad like the entire IPv6 stack, or entire TPM support.)

So: if the people doing FIPS certifications of the whole kernel make a
determination that fips_enabled=1 kernels must not support IPv6 Segment
Routing with HMAC-SHA1 authentication, then they're welcome to send a
patch that makes seg6_genl_sethmac() reject SEG6_HMAC_ALGO_SHA1 if
fips_enabled.  And that would actually correctly disable the SHA-1
support only, rather than disabling the entire IPv6 stack...

Still, for many years lib/ has had APIs for SHA-1 and various
non-FIPS-approved crypto algorithms.  These are used even when
fips_enabled=1.  So, if this was actually important, one would think
these cases would have addressed already.  This is one of the reasons
why I haven't been worrying about adding these checks myself.

It's really up to someone who cares (if anyone does) to send patches.

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.

As I've said in another thread
(https://lore.kernel.org/linux-crypto/20250917184856.GA2560@quark/ (local),
https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/ (local)),
small patches that add FIPS pre-operational self-tests would generally
be fine, if they are shown to actually be needed and are narrowly scoped
to what is actually needed.  These would be different from and much
simpler than the KUnit tests, which are the real tests.

But again, it's up to someone who cares to send patches.  And again,
lib/ has had SHA-1 since 2005, so this isn't actually new.

- Eric