linux-kernel - Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

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

Message-ID: <57505261-45EA-48B6-824E-49AF2203C094@zytor.com>
Date: Tue, 18 Mar 2025 12:25:34 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>, mingo@...nel.org,
        linux-kernel@...r.kernel.org
CC: Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "Ahmed S . Darwish" <darwi@...utronix.de>,
        John Ogness <john.ogness@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

On March 18, 2025 12:09:59 PM PDT, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
>On 18/03/2025 6:48 pm, H. Peter Anvin wrote:
>> One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.
>
>It's not only the feature-enabling MSRs.  It's also OSXSAVE/OSPKE/etc in
>CR4, and on Intel CPUs, the CPUID instruction still has a side effect
>for microcode patch revision MSR.
>
>There are a few too many side effects to call it const/pure.
>
>That said, when experimenting with the same in Xen, there was nothing
>interesting the compiler could do with const/pure because of how the
>existing logic is laid out.  Removing volatile and the memory clobber
>however did allow the compiler to make slightly better code.
>
>~Andrew

Well, I guess I lump CRs, DRs and MSRs together. There is also CPUID for serialization, which is really a totally different use for the same instruction. 

tglx has suggested that we should cache or even preload the cpuid data (the latter would have the potential advantage of making the memory data structures a little easier to manage, given the very large potential space.)

The biggest issue is that there is no general mechanism for detecting which cpuid leaves have subleaves, and if they do, how many. I *believe* all existing subleaf sets are dense, but one could at least hypothetically see a vendor or VM define a CPUID leaf with a sparse subleaf set.