Re: [GIT PULL] Crypto Update for 6.17

Re: [GIT PULL] Crypto Update for 6.17

[Herbert Xu]

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [GIT PULL] Crypto Update for 6.17

[Jiri Slaby]

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?

-- 
js
suse labs

Re: [GIT PULL] Crypto Update for 6.17

[Jiri Slaby]

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?

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@

thanks,
-- 
js
suse labs

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

[Jiri Slaby]

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?
> 
> 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@kernel.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?

thanks,
-- 
js
suse labs

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

[Herbert Xu]

On Thu, Oct 02, 2025 at 12:57:11PM +0200, Jiri Slaby wrote:
>
> 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@kernel.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?

Yes that works too.  But it's basically the same as reverting
the patch from Vegard since it makes the code use SHA1 again
even though we told it not too.

Perhaps we should just revert Vegard's change? Since it's kind
of pointless now that people are just using the underlying SHA1
algorithm directly through lib/crypto.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Vegard Nossum]

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@kernel.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, 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?

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.


Vegard

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

[Eric Biggers]

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

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

[Vegard Nossum]

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

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

[Eric Biggers]

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

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

[Linus Torvalds]

On Mon, 6 Oct 2025 at 04:53, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> 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.

I think the other way of writing that is "fips=1 is and will remain
irrelevant in the real world as long as it's that black-and-white".

             Linus

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

[Vegard Nossum]

On 06/10/2025 18:19, Linus Torvalds wrote:
> On Mon, 6 Oct 2025 at 04:53, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>>
>> 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.
> 
> I think the other way of writing that is "fips=1 is and will remain
> irrelevant in the real world as long as it's that black-and-white".

Okay, so I get that we don't like fips=1 around here (I'm not a
particularly big fan myself), but what's with the snark? fips=1 exists
in mainline and obviously has users. I'm just trying to make sure it
remains useful and usable. Otherwise we're going back to the
jitterentropy situation where every distro has their own downstream
patches to pass FIPS certification. Is that what you want?

Confused,


Vegard

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

[Linus Torvalds]

On Mon, 6 Oct 2025 at 09:32, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> Okay, so I get that we don't like fips=1 around here (I'm not a
> particularly big fan myself), but what's with the snark? fips=1 exists
> in mainline and obviously has users. I'm just trying to make sure it
> remains useful and usable.

It literally caused non-bootable machines because of that allegedly
"remains useful and usable" because it changed something that never
failed to failing. That's how this thread started.

So that's why the snark. I think you are deluding yourself and others
if you call that "useful and usable".

           Linus

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

[Vegard Nossum]

On 06/10/2025 18:19, Linus Torvalds wrote:
> I think the other way of writing that is "fips=1 is and will remain 
> irrelevant in the real world as long as it's that black-and-white".

On 06/10/2025 19:11, Linus Torvalds wrote:
> On Mon, 6 Oct 2025 at 09:32, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>>
>> Okay, so I get that we don't like fips=1 around here (I'm not a
>> particularly big fan myself), but what's with the snark? fips=1 exists
>> in mainline and obviously has users. I'm just trying to make sure it
>> remains useful and usable.
> 
> It literally caused non-bootable machines because of that allegedly
> "remains useful and usable" because it changed something that never
> failed to failing. That's how this thread started.
> 
> So that's why the snark. I think you are deluding yourself and others
> if you call that "useful and usable".

Yes, thank you, I've already acknowledged that my patch caused boot
failures and I apologize for that unintentional breakage. Why does this
mean we should throw fips=1 in the bin, though? That's a total non sequitur.

The fact is that fips=1 is not useful if it doesn't actually result
something that complies with the standard; the only purpose of fips=1 is
to allow the kernel to be used and certified as a FIPS module. But as
SHA-1 is still allowed for now, please go ahead and revert my patch,
it's commit 9d50a25eeb05c.


Vegard

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

[Eric Biggers]

On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
> The fact is that fips=1 is not useful if it doesn't actually result
> something that complies with the standard; the only purpose of fips=1 is
> to allow the kernel to be used and certified as a FIPS module.

Don't all the distros doing this actually carry out-of-tree patches to
fix up some things required for certification that upstream has never
done?  So that puts the upstream fips=1 support in an awkward place,
where it's always been an unfinished (and undocumented) feature.

- Eric

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

[Linus Torvalds]

On Mon, 6 Oct 2025 at 12:12, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> Yes, thank you, I've already acknowledged that my patch caused boot
> failures and I apologize for that unintentional breakage. Why does this
> mean we should throw fips=1 in the bin, though?

That's not what I actually ever said.

I said "as long as it's that black-and-white". You entirely ignored that part.

THAT was my point. I don't think it makes much sense to treat this as
some kind of absolute on/off switch.

So I would suggest that "fips=1" mean that we'd *WARN* about use of
things like this that FIPS says should be off the table in 2031.

The whole "disable it entirely" was a mistake. That's obvious in
hindsight. So let's *learn* from that mistake and stop doing that.

If somebody is in a situation where they really need to disable SHA1,
I think they should hard-disable it and just make sure it doesn't get
compiled in at all.

But for the foreseeable immediate future, the reasonable thing to do
is AT MOST to warn about fips rules, not break things.

Because the black-and-white thing is obviously broken. One boot
failure was enough - we're *NOT* doubling down on that mistake.

                Linus

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

[Simo Sorce]

On Mon, 2025-10-06 at 19:26 +0000, Eric Biggers wrote:
> On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
> > The fact is that fips=1 is not useful if it doesn't actually result
> > something that complies with the standard; the only purpose of fips=1 is
> > to allow the kernel to be used and certified as a FIPS module.
> 
> Don't all the distros doing this actually carry out-of-tree patches to
> fix up some things required for certification that upstream has never
> done?  So that puts the upstream fips=1 support in an awkward place,
> where it's always been an unfinished (and undocumented) feature.

FWIW downstream patching, at least until recently, has been minimal.
The upstream behavior has been good enough to be representative of the
behavior you would expect from a certified binary.

Note: this may change going forward, but I am confident that as issues
arise people will propose upstream patches to keep it as close as
possible within acceptable parameters for upstream behavior.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

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

[Vegard Nossum]

On 06/10/2025 21:26, Eric Biggers wrote:
> On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
>> The fact is that fips=1 is not useful if it doesn't actually result
>> something that complies with the standard; the only purpose of fips=1 is
>> to allow the kernel to be used and certified as a FIPS module.
> 
> Don't all the distros doing this actually carry out-of-tree patches to
> fix up some things required for certification that upstream has never
> done?  So that puts the upstream fips=1 support in an awkward place,
> where it's always been an unfinished (and undocumented) feature.

I can't speak for all distros, but we have a handful of patches, around
6 or 7 I believe, most are fairly small. (We are, however, looking to
move to the standalone module I sent the RFC for, which has a lot more
patches...)

But yes, mainline fips=1 support is in a slightly awkward place. I see
no real reason for anybody to ever use it in production unless it's
actually a NIST certified build either.

That doesn't mean we shouldn't try to minimize the amount of downstream
patches, though. (IMHO, anyway.)

I would like to try to document what fips=1 is currently and how to use
it and how to program for it (if nobody -- however unlikely -- beats me
to it). I came across this thread from over 10 years ago where people
are asking about the kernel FIPS docs and we still don't have any:

https://mta.openssl.org/pipermail/openssl-users/2015-March/000904.html


Vegard

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

[Theodore Ts'o]

On Mon, Oct 06, 2025 at 03:45:46PM -0400, Simo Sorce wrote:
> Note: this may change going forward, but I am confident that as issues
> arise people will propose upstream patches to keep it as close as
> possible within acceptable parameters for upstream behavior.

What I'm curious about is what falls within the acceptable parameters
of *distro* behavior.  If NIST-certified labs really insist that
certifying requires making the kernel completely unsupportable from a
commercial perspective, at what point will *distros* decide to give it
up as a bad idea, or to have a completely different binary kernel
package that only crazy customers would be willing to use?

If there is something beyond hard-disabling CONFIG_CRYPTO_SHA1 which
all distributions could agree with --- what would that set of patches
look like, and would it be evenly vaguely upstream acceptable.  It
could even hidden behind CONFIG_BROKEN.  :-)

						- Ted
						

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

[Linus Torvalds]

On Wed, 8 Oct 2025 at 05:13, Theodore Ts'o <tytso@mit.edu> wrote:
>
> If there is something beyond hard-disabling CONFIG_CRYPTO_SHA1 which
> all distributions could agree with --- what would that set of patches
> look like, and would it be evenly vaguely upstream acceptable.  It
> could even hidden behind CONFIG_BROKEN.  :-)

Maybe just

 (a) make it a runtime flag - so that it can't mess up the boot, at least

 (b) make it ternary so that you get a "warn vs turn off"

 (c) and allow people to clear it too - so that you can sanely *test*
it without forcing a possibly unusable machine

and then

 (d) make the clearing be dependent on that 'lockdown' set that nobody
remotely normal uses anyway

would make this thing a whole lot more testable, and a whole lot less abrupt.

Christ, if even FIPS went "we know this is a big thing, we'll give you
a decade to sort things out", then the kernel damn well shouldn't make
it some black-and-white sudden flag.

So we should *NOT* say "FIPS says turn it off eventually, so we should
turn it off". No. That was very very wrong.

We should say "FIPS says turn it off eventually, so we should give
users simple tools to find problem spots".

And that "simple tools" very much is about not making it some kind of
"Oh, what happens is that the machine is unusable". It should be that
"Oh, look, now it gives a warning that I would have a problem in XYZ
if it wasn't available".

                   Linus