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: <A50E7745-759B-462D-BA7C-C9F747070F91@zytor.com>
Date: Tue, 06 May 2025 10:51:16 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "Maciej W. Rozycki" <macro@...am.me.uk>, 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 May 6, 2025 10:11:04 AM PDT, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Tue, 6 May 2025 at 09:44, H. Peter Anvin <hpa@...or.com> 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".
>
>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.
>
>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.
>
>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.
>
>(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)
>
>             Linus

Yes, the patch will be bigger, but it's just a bunch of highly static code copied straight out of the current kernel with very few touch points to the rest of the kernel (which is why we didn't axe it together with i386 support. Now that one was ugly, with touch points all over the place.)

It is basically the same idea as the arch/i486 I suggested, just in a separate git tree (although I guess I don't really see how this is fundamentally different than, say, arch/m68k.)

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.)

As far as I know, Transmeta Crusoe was the only i586-class CPU which supported SYSENTER (if that version of the firmware even shipped, I'm not sure), and Crusoe was "almost" i686 class in terms of ISA (mainly lacking PAE and NOPL, and having P5-like flags behavior.)

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...)

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

   -hpa

* – I believe there was one version of the Pentium M which didn't have PAE, at least officially, although I understand that if you flipped the CR4 bit it actually worked. I am guessing, without any concrete evidence, that there was a timing path and that it would fail at the highest operating temperatures on some subset of chips.