linux-kernel - Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less CPUs

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: <alpine.DEB.2.21.2505062256170.21337@angie.orcam.me.uk>
Date: Thu, 8 May 2025 15:53:09 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>, 
    linux-kernel@...r.kernel.org, "Ahmed S . Darwish" <darwi@...utronix.de>, 
    Andrew Cooper <andrew.cooper3@...rix.com>, 
    Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...nel.org>, 
    Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, 
    John Ogness <john.ogness@...utronix.de>, 
    Peter Zijlstra <peterz@...radead.org>, 
    Thomas Gleixner <tglx@...utronix.de>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Subject: Re: [RFC PATCH 0/15] x86: Remove support for TSC-less and CX8-less
 CPUs

On Tue, 6 May 2025, Linus Torvalds wrote:

> > a. Someone would have to take it on;
> > b. It will need continuous testing;
> > c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
> 
> I think the main issue is "when problems happen, people who
> *shouldn't* have to care get reports".

 FWIW I can't agree more here.

> I really think that the way forward is basically what we did for ia64:
> get rid of i486 support in mainline, and people who care about i486
> can maintain a smallish patch that basically keeps it alive for them.
> 
> Because I suspect that the "patch to keep it working in practice" is
> likely going to remain pretty small: it's the silly cmpxchg helper
> wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
> X86_FEATURE_CX8 tests.

 Why would these have to be disabled if we have CMPXCHG8B emulation?  Yes,
performance won't be stellar, but we talked it through already in the 
context of my recent EV4 Alpha effort.  People ran FPU emulation back in 
the day too rather than using soft-float, which would have surely reduced 
the handling overhead.

> And it probably (a) works fine and (b) won't be code that changs very
> much upstream, so maintaining it outside the main tree is likely not a
> lot of work.

 Conversely dropping support for a subtarget in the kernel will likely 
prompt the removal on the userland side, namely glibc, which will only 
complicate things.

> But because it's outside of the main tree, it won't cause pointless
> noise from 0day bots etc, and won't affect people who care about
> modern machines. And it can do various hacky things because the patch
> would *only* be used by people who actually run on an i486-class
> machine.

 This is a fair point, although I'm not sure why the bots are expected to 
complain about a piece of code once it's settled and does not change.  I 
can't recall any mailing list traffic about MIPS instruction emulation for 
legacy systems (and we made it a part of the uABI even) in what? -- 20 
years or so.

 And I'd prefer to stay away from hacks even at the cost of performance.  
I don't find the emulation of CMPXCHG8B and maybe RDTSC if really needed 
(possibly in a trivial way, such as returning an incrementing software 
counter) a hack, but evolution.  It has happened before.

> (Ok, if you actually care about the i486SX, the patch will be much
> bigger, because it will have that whole FPU emulation code in it)

 FWIW I'm fine to see FPU emulation code go, especially as it's something 
that can be sorted in the userland for the so inclined.  Or you can run a 
soft-float userland, for example in the form of a GCC multilib just as 
done with numerous targets.

  Maciej