[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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