Message-ID: <20251006161225.GC1637@sol>
Date: Mon, 6 Oct 2025 09:12:25 -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>,
	Theodore Ts'o <tytso@....edu>, "nstange@...e.de" <nstange@...e.de>,
	"Wang, Jay" <wanjay@...zon.com>
Subject: Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL]
 Crypto Update for 6.17]

On Mon, Oct 06, 2025 at 01:53:21PM +0200, Vegard Nossum wrote:
> On 02/10/2025 19:23, Eric Biggers wrote:
> > On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:
> > > 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.
> 
> Sure, it was available under lib/ but what matters is that there were no
> users outside of the crypto API.

That's incorrect.  The SHA-1 library was already used by
kernel/bpf/core.c and net/ipv6/addrconf.c.  And also
drivers/char/random.c prior to 5.17.

> Adding direct users presumably breaks the meaning of fips=1 -- which
> is why I'd like us to work out (and explicitly document) what fips=1
> actually means.

Well, fips=1 has never had any documentation.  If anyone cares they
should document it.

But also, as I said, if certain kernel subsystem(s) mustn't use certain
algorithms when fips=1, then the people who care about FIPS are welcome
to add that logic to those subsystems.  It's trivial:

    #include <linux/fips.h>

    if (fips_enabled)
            return -EOPNOTSUPP;

Sure, it's 3 lines per subsystem, but compare that to the 50-200 that
typically gets saved by switching to the library.  And the library
solves a number of other problems too.  So it's still well worth it.

I'll plan to add these checks to MD5 uses when doing MD5 conversions in
6.19.  Yes, I didn't add them to SHA-1 uses when doing SHA-1 conversions
in 6.18, but it's clear that disallowing SHA-1 is still a
work-in-progress anyway.  I'll assume that you or someone else are going
to finish the work for SHA-1 at some point.

> > 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.
> 
> I see some direct uses of lib/ algorithms outside the crypto API on
> older kernels but at a glance they look mostly like specific drivers
> that most distros probably don't even build, which might explain why it
> hasn't been a problem in practice.

Again, incorrect.  Core kernel functionality uses, and continues to use,
non-FIPS-approved crypto algorithms.

Maybe the FIPS people assessed each of those use cases and determined
that they are not "security functions".  But I and other upstream kernel
developers have no visibility into that.

More likely IMO is that the FIPS people are just ignoring reality.

> I'd assume most distributions that provide FIPS-certified kernels care.
> As far as I can tell, they are all going to run into problems when they
> start providing products based on v6.17. Maybe I'm wrong and it comes
> down to an interpretation of FIPS requirements and what fips=1 is
> intended to do -- again, why I'd like us to work this out and document
> it so we have a clear and shared understanding and don't break mainline
> FIPS support.
> 
> In the meantime, I think it would be good to stop converting more crypto
> API users to lib/crypto/ users if it's not crystal clear that it's not a
> "security function".

You're welcome to be constructive instead of obstructive.

> > > 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.
> 
> What's new is the direct user of lib/crypto/sha1.c outside the crypto
> API since commit 095928e7d8018, which is very recent.

Again: while that particular user is new, the SHA-1 library was already
used by kernel/bpf/core.c and net/ipv6/addrconf.c.

> I don't think it's a good idea to duplicate all the logic around
> FIPS and algorithm testing that already exists in the crypto API for
> this exact purpose.

As I've said: if the pre-operational self-tests are actually needed in
lib/ after all, then lib/ can just implement the minimum that FIPS
requires, which is actually quite straightforward (typically just a
single check for algorithm).

I don't see it as duplicating the actual tests.  The way that
crypto/testmgr.c conflates the FIPS pre-operational self-tests and the
actual tests has always been really problematic.

- Eric

Powered by blists - more mailing lists