linux-kernel - Re: Code archaeology - 3DNow vs Pending Break Enable

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: <800773c2-40c5-4c8b-87d5-e327db46985a@citrix.com>
Date: Tue, 25 Nov 2025 23:07:22 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 "H. Peter Anvin" <hpa@...or.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
 the arch/x86 maintainers <x86@...nel.org>,
 Christian Ludloff <ludloff@...il.com>
Subject: Re: Code archaeology - 3DNow vs Pending Break Enable

On 25/11/2025 10:40 pm, Andrew Cooper wrote:
> Hello,
>
> init_amd() has the following curious code:
>
>         /*
>          * Bit 31 in normal CPUID used for nonstandard 3DNow ID;
>          * 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway
>          */
>         clear_cpu_cap(c, 0*32+31);
>
>
> as has Centaur and Cyrix.  Amazingly, besides formatting, this appears
> to be unchanged since "Massive cleanup of CPU detection and bug
> handling; Transmeta CPU detection, H. Peter Anvin <hpa@...or.com>,
> November 2000".
>
> https://github.com/schwabe/davej-history/commit/67ad24e6d39c3bc4618e7eb0563ccde3d76d0a51#diff-ab4c065cef7ebcd6d255c47ed4c3c0a77da8ad3df004dab9a183cc88814730ff
> is the only working mirror I can find online.
>
> When AMD added 3DNow, it was only in extended CPUID. 
> https://datasheets.chipdb.org/AMD/All%20CPU/20734j.pdf notes that other
> vendors implemented 3DNow, and Centaur does have extra logic to
> re-activate 3DNow.
>
> I realise I'm asking a lot, but do you remember why this clear of PBE
> was added?
>
> It looks out of place even at the time of adding.  The x86_capability
> backing memory was zeroed shortly before, and only only written into by
> a correct looking cpuid(1) invocation.
>
> Was there really a CPU which misreported it in basic CPUID, or is there
> some other reason for it?

Actually, on further consideration, the code layout on the preceding
commit (2.4.0-test11pre4 079dff3979df846 in the mirror) might explain
things.

X86_FEATURE_AMD3D was 0x80000000, and init_cyrix() was putting it in
c->x86_capability (because there was only a single bitmap) one case by
probing, and one case from reading it it out of extended CPUID.

So, this looks like it may have been a logical issue prior to "Massive
cleanup" separating the c->x86_capability field into an array, and ought
to have been cleaned up too.

In which case I think it's safe to retire the logic.

~Andrew