Message-ID: <20251002172310.GC1697@sol>
Date: Thu, 2 Oct 2025 10:23:10 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Vegard Nossum <vegard.nossum@...cle.com>
Cc: Jiri Slaby <jirislaby@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>
Subject: 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:
> > On 02. 10. 25, 12:13, Jiri Slaby wrote:
> > > On 02. 10. 25, 12:05, Jiri Slaby wrote:
> > > > On 02. 10. 25, 11:30, Herbert Xu wrote:
> > > > > On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
> > > > > > On 29. 07. 25, 13:07, Herbert Xu wrote:
> > > > > > > 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.
> 
> > > 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 <ebiggers@...nel.org>
> > 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/,
https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/),
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

Powered by blists - more mailing lists