[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj7TAP8fD42m_eaHE23ywfp7Y2ciqeGC=ULsKbuVTdMrg@mail.gmail.com>
Date: Mon, 6 Oct 2025 12:29:47 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vegard Nossum <vegard.nossum@...cle.com>
Cc: Eric Biggers <ebiggers@...nel.org>, Jiri Slaby <jirislaby@...nel.org>,
Herbert Xu <herbert@...dor.apana.org.au>, "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, 6 Oct 2025 at 12:12, Vegard Nossum <vegard.nossum@...cle.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
Powered by blists - more mailing lists