linux-kernel - Re: [PATCH v4 00/34] x86: Introduce a centralized CPUID data model

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: <ebab779b93b8be44bd5089ae6ecc9746b1517a68.camel@infradead.org>
Date: Sat, 16 Aug 2025 10:59:43 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Ahmed S. Darwish" <darwi@...utronix.de>, Borislav Petkov
 <bp@...en8.de>,  Ingo Molnar <mingo@...hat.com>, Dave Hansen
 <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Andrew Cooper
 <andrew.cooper3@...rix.com>, "H. Peter Anvin" <hpa@...or.com>, Sean
 Christopherson <seanjc@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
 Sohil Mehta <sohil.mehta@...el.com>,  John Ogness
 <john.ogness@...utronix.de>, x86@...nel.org, x86-cpuid@...ts.linux.dev,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 00/34] x86: Introduce a centralized CPUID data model

On Fri, 2025-08-15 at 09:01 +0200, Ahmed S. Darwish wrote:
> 
> This series introduces a centralized CPUID model for the x86
> subsystem.
> 
> Rationale for this work can be found at:
> 
>     https://lore.kernel.org/lkml/874ixernra.ffs@tglx
> 
>     https://gitlab.com/x86-cpuid.org/x86-cpuid-db
> 
> The first 5 patches can be independently applied.

Nice work. Looks like you haven't attempted to address hypervisor CPUID
yet. I've attempted to document that in a section at the end of 
http://david.woodhou.se/ExtDestId.pdf — I wonder if we should find
somewhere to publish it as canonical?

I suspect our loop in cpuid_base_hypervisor() should be 'fixed' to
comply with the new rule I just made up, that it should only scan each
block at 0x4000_0.00 until it finds an empty block, rather than going
all the way up to 0x4001_0000?

Are there any hypervisors which provide more than one block, that
*aren't* just putting the Hyper-V leaves at 0x4000_0000 and their own
native leaves at 0x4000_0100 ?

Even when we support Xen under KVM we expose *only* the Xen leaves and
don't put the KVM leaves at 0x4000_0100 too.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)