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 for Android: free password hash cracker in your pocket

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

Message-ID: <A5AC3B8B-335C-4594-B0DC-D9247B286A37@zytor.com>
Date: Tue, 06 May 2025 09:44:01 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>,
        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>,
        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 6:53:34 AM PDT, "Maciej W. Rozycki" <macro@...am.me.uk> wrote:
>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

However, building a #UD instruction emulator is a project in itself that someone would have to take on. It isn't inherently simpler – quite the opposite – than the alternatives calling to a stub function than we have now.

We have the tools to do it; there is now a full x86 instruction decoder in the kernel that one could use to do this, but...

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.

And at some point we will be at a point where we were with i386 that the only users are occasional testers.

With regards to EISA, you still haven't clarified if there is a true use case or if this is a museum/nostalgia project. There isn't anything *wrong* with museum projects, not at all (I recently got to play SPACEWAR! on a real PDP-1; it was amazing) but imposing a maintenance burden on the mainline developers of one of the most heavily used architecture on the planet is not practical.

If someone really wanted to, they could maybe fork off, say, arch/i486 and maintain the a version of the kernel limited to these old machines, but it would require someone being willing to do the work.