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: <aXdmc6F5wLthVDEU@lx-t490>
Date: Mon, 26 Jan 2026 14:04:51 +0100
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Sean Christopherson <seanjc@...gle.com>,
	David Woodhouse <dwmw2@...radead.org>,
	"H. Peter Anvin" <hpa@...or.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 v5 07/35] x86: Introduce a centralized CPUID data model

Hi Boris,

On Fri, 16 Jan 2026, Borislav Petkov wrote:
>
> Btw, why are we calling them dynamic?
>
> This is confusing. Those leafs simply have multiple subleafs specified
> in ECX.
>
> Let's please not invent our own things here but simply stick to the
> nomenclature in the vendor docs.
>
> This is a very simple explanation IMO:
>
> "The information is accessed by (1) selecting the CPUID function setting
> EAX and optionally ECX for some functions,"
>
>
> and there's no talk about dynamic and whatnot.
>
...
>
> This is where the problem lies: you're calling static leaves those which
> have one subleaf and dynamic those which have multiple.
>
> But if one "static" leaf starts adding subleafs, the "static" one
> becomes "dynamic". And that's confusing. Nothing dynamic about it. You
> simply have CPUID leafs with 1 or more subleafs. And that should be the
> nomenclature we use.
>

Due to the differing leaf/subleaf output formats, at
arch/x86/include/asm/cpuid/leaf_types.h we have the storage types:

    struct leaf_0x4_n	{ ... };	// CPUID(0x4),  subleaves 0 -> n

    struct leaf_0xd_0	{ ... };	// CPUID(0xd),  subleaf 0
    struct leaf_0xd_1	{ ... };	// CPUID(0xd),  subleaf 1
    struct leaf_0xd_n	{ ... };	// CPUID(0xd),  subleaves 2 -> n

    struct leaf_0x10_0	{ ... };	// CPUID(0x10), subleaf 0
    struct leaf_0x10_n	{ ... };	// CPUID(0x10), subleaves 1 -> n

where "n" is known at runtime.

Then, for CPUID(0xd) subleaf 0 and 1 call sites we have:

    /*
     * "Static" access
     */

    const struct leaf_0xd_0 *ld_0;
    const struct leaf_0xd_1 *ld_1;

    ld_0 = cpuid_subleaf(c, 0xd, 0);
//                       |   |   └────────┐
//                       |   └─────────┐  |
//                       *             *  *
//  ld_0 =              &c.cpuid.leaf_0xd_0[0];

    ld_1 = cpuid_subleaf(c, 0xd, 1);
//                       |   |   └────────┐
//                       |   └─────────┐  |
//                       *             *  *
//  ld_1 =              &c.cpuid.leaf_0xd_1[0];

And for CPUID(0xd) subleaves 2 to n, we have:

    /*
     * "Dynamic" access
     */

    const struct leaf_0xd_n *ld;
    for (int i = XFEATURE_SSE; i < XFEATURE_MAX; i++) {
	ld = cpuid_subleaf_n(c, 0xd, i);
//                           |   |   └──────────┐
//                           |   └─────────┐    |
//                           *             *    *
//      ld =                &c.cpuid.leaf_0xd_n[i];
    }

Similarly, for CPUID(0x4) call sites we have:

    /*
     * "Dynamic" CPUID(0x4) subleaf access, 0 -> n
     */

    const struct leaf_0x4_n *l4;
    for (int i = 0; i < cpuid_subleaf_count(c, 0x4); i++) {

	l4 = cpuid_subleaf_n(c, 0x4, i);
//                           |   |   └──────────┐
//                           |   └─────────┐    |
//                           *             *    *
//      l4 =                &c.cpuid.leaf_0xd_n[i];
    }

So the root-cause of all these "static" vs. "dynamic" distinctions was to
catch call sites, at compile-time, when using the wrong CPUID storage
output type relative to the requested leaf/subleaf.

I'll get rid of this static/dynamic terminology and think of something
better.

(and an ACK for all the other snipped remarks.)

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ