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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2505062301010.21337@angie.orcam.me.uk>
Date: Thu, 8 May 2025 15:54:42 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "H. Peter Anvin" <hpa@...or.com>
cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
    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, H. Peter Anvin wrote:

> An i486/i586 retroport can presumably also axe a bunch of things like 
> side channel mitigations; most of them aren't applicable to the in-order 
> i486/586 pipelines and the rest ... well, on a machine that slow, you 
> are unlikely to be running the kind of workloads that care.
> 
> Similarly, you should be able to simply unsupport the things that make 
> the entry/exit code a nightmare, like SYSENTER and fancy NMI hacks (the 
> latter requires an APIC.)

 I do have a dual i586 with an APIC; used it to work on some NMI watchdog 
stuff that landed in mainline 25+ years ago.  Back in the day such systems 
were pretty common, built around the NX or later the HX chipset, so it's 
not that APIC support is irrelevent could be dropped.  If we were to go 
for a separate port, than stuff could potentially be resurrected too that 
was previously removed, such as discrete i82489DX APIC support.

 NB that box actually still runs some server software I need for my lab 
(MOP daemon, needed to netboot various DEC equipment) that I haven't 
ported to POWER9 owing to higher priority items.

> There is a huge gap then to the i686, with the i686 being the direct 
> ancestor of the x86-64 systems in terms of systems architecture (APIC, 
> PAE*, etc; SYSENTER in the second iteration; a general tightening of the 
> ISA definition; PCI universal by then...)

 I suspect eventually we'll want to drop all IA-32 support from mainline; 
isn't it of no commercial relevance already?  Hasn't even the embedded x86 
ecosystem switched to 64-bit Atom and the like?

 Actually I think a project to maintain the whole IA-32 platform alive 
rather than just the i486 subtarget might attract more attention and 
people beyond just myself and Adrian.  So far I've committed to support 
across the board (Linux where applicable and the GNU toolchain) for DEC 
Alpha, MIPS and VAX platforms plus a couple of small pieces such as the 
defxx driver and I can hardly cope already, so taking on another large 
project just won't work if I were alone with it.

> But again, this is all academic unless someone steps up and wants to 
> take on such a project.

 Correct, I just want to keep support to the minimum at the moment.

  Maciej