Message-ID: <2981dc1d-287f-44fc-9f6f-a9357fb62dbf@oracle.com>
Date: Mon, 6 Oct 2025 13:53:21 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Eric Biggers <ebiggers@...nel.org>
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 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. 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.

>> 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...

I'm pretty sure the use of SHA-1/HMAC inside IPv6 segment routing counts
as a "security function" (as it is used for message authentication) and
thus should be subject to FIPS requirements when booting with fips=1.

> 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.

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

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".

>> 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.

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.


Vegard

Powered by blists - more mailing lists