linux-kernel - Re: [GIT PULL] Crypto library fix for v6.16-rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wiT=UUcgCVVo5ui_2Xb9fdg4JrPK=ZqpPxDhCgq9vynDg@mail.gmail.com>
Date: Fri, 27 Jun 2025 17:54:05 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Ard Biesheuvel <ardb@...nel.org>, "Jason A. Donenfeld" <Jason@...c4.com>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [GIT PULL] Crypto library fix for v6.16-rc4

On Fri, 27 Jun 2025 at 11:15, Eric Biggers <ebiggers@...nel.org> wrote:
>
> Fix a regression where the purgatory code sometimes fails to build.

Hmm. This is obviously a fine and simple fix, but at the same time it
smells to me that the underlying problem here is  that the purgatory
code is just too damn fragile, and is being very incestuous with the
sha2 code.

The purgatory code tends to be really special in so many other ways
too (if you care, just look at how it plays games with compiler flags
because it also doesn't want tracing code etc).

And when it comes to the crypto code, it plays games with just
re-building the sha256.c file inside the purgatory directory, and is
just generallyt being pretty hacky.

Anyway, I've pulled this because as long as it fixes the issue and you
are ok with dealing with this crazy code I think it's all good.

But I also get the feeling that this should be very much seen as a
purgatory code problem, not a crypto library problem.

We seem to have the same hacks for risc-v, s390 and x86, and I wonder
if the safe thing to do long-term from a maintenance sanity standpoint
would be to just make the purgatory code hackery use the generic
sha256 implementation.

I say that purely as a "maybe it's not a good idea to mix the crazy
purgatory code with the special arch-specific optimized code that may
need special infrastructure".

The fact that the x86 sha256 routines do that whole irq_fpu_usable()
thing etc is a symptom of that kind of "the architecture code is
special".

But as long as you are fine with maintaining that arch-optimized code
knowing that it gets (mis-)used by the strange purgatory code, I
certainly don't mind the status quo with that one-liner fix.

So I guess this email is just me saying "if this keeps triggering
problems, just make the purgatory code use the slow generic routines".

Because it's not necessarily worth the pain to support arch-optimized
versions for that case.

If there is pain, that is.

                    Linus