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.2505061104490.31828@angie.orcam.me.uk>
Date: Tue, 6 May 2025 14:53:34 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: 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>, 
    "H . Peter Anvin" <hpa@...or.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 Mon, 5 May 2025, Linus Torvalds wrote:

> >  We also have platforms that lack atomics, let alone double-precision ones
> > and they're fine too, so why is x86 different?
> 
> So I don't know if you saw this thread:
> 
>    https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
> 
> where I initially thought that it was the lack of TSC, but it looks
> like it's the CMPXCHG8B code that ends up causing problems.

 I did glance over (in my effort to process outstanding 40k mailing list 
messages in two days), but haven't spotted CMPXCHG8B being the culprit; 
thanks for the pointer.

> And the core issue boils down to "there's no point in wasting time on
> even debugging this".

 Sadly I tend to agree, being unable, owing to time constraints, to commit 
myself to doing such debugging (NB glibc verification crashes i386 Linux 
reliably on Pentium MMX, apparently due to FP context corruption, and I 
need to prioritise debugging that, once I've figured out which actual test 
case triggers it, as due to the oddity of the glibc test system it's quite 
tough getting the logs matched between the host and the target system).

> So basically, the support for i486 costs us more than it is worth.

 So the cost has to be reduced and just as I proposed on the previous 
iteration last year this can be solved quite easily without sacrificing 
i486 support by adding #UD handler for CMPXCHG8B, just as we did for 
analogous stuff with some RISC platforms years if not decades ago.

 I was told in said discussion that decoding x86 address modes was not as
easy as with RISC modes (thank you, Captain Obvious!), but still that 
boils down to indexing into registers by ModR/M and SIB bit-fields, with a 
couple of corner cases, which ought to be less than a screenful of code.  
If objdump(1) can do it, so can we.

 No i486 has ever run Linux SMP.  Back in the day I tried hard to chase by 
the spec a single i486 system built around the APIC and Intel MP Spec and 
could not find any.  Compaq had some proprietary stuff (Corollary bus?) we 
never had support for.  And we discarded support for the discrete i82489DX 
APIC years ago anyway that some Pentium systems used too for the original 
P5 microarchitecture or to go beyond dual.  So said emulation would have 
to handle the UP case only, which ought to be straightforward and well 
contained.

 Thoughts?

  Maciej