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

Message-ID: <2cd980dd-4342-4bc5-afe6-0548dedfaf24@citrix.com>
Date: Tue, 25 Nov 2025 22:40:02 +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>,
 Andrew Cooper <andrew.cooper3@...rix.com>,
 Christian Ludloff <ludloff@...il.com>
Subject: Code archaeology - 3DNow vs Pending Break Enable

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?

Thanks,

~Andrew