linux-kernel - Re: [ANNOUNCE] x86-cpuid-db: Release v2.0

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: <ZwVTVO2FcH95WFBp@lx-t490>
Date: Tue, 8 Oct 2024 17:44:20 +0200
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: x86-cpuid@...ts.linux.dev, Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Sohil Mehta <sohil.mehta@...el.com>,
	John Ogness <john.ogness@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] x86-cpuid-db: Release v2.0

Hi Andrew,

On Tue, 08 Oct 2024, Andrew Cooper wrote:
>
> On 08/10/2024 2:31 pm, Ahmed S. Darwish wrote:
> > to:
> >
> >     /*
> >      * Leaf 0x0
> >      * Maximum standard leaf number + CPU vendor string
> >      */
> >
> >     struct leaf_0x0_0 {
> >         ...;
> >     };
> >
> >     /*
> >      * Leaf 0x7
> >      * Extended CPU features enumeration
> >      */
> >
> >     struct leaf_0x7_0 {
> >         ...;
> >     };
> >
> >     struct leaf_0x7_1 {
> >         ...;
> >     };
> >
> > Overall, this removes ambiguity for IDs like 0x16, and improves kernel
> > code greppability (x86 PQ pending).
>
> So what does leaf 0xd with 62 subleaves look like.  Do we really have
> one number in hex, and one in decimal?

Hmmm, good point...

For now, if we grep the generated C linux header for all the structures
that are not subleaf 0, we get:

    $ grep -E 'struct leaf_0x[0-9a-f]+_[^0]' cpuid-bitfields.h

    struct leaf_0x7_1 {
    struct leaf_0x7_2 {
    struct leaf_0xd_1 {
    struct leaf_0xd_2 {
    struct leaf_0xf_1 {
    struct leaf_0x10_1 {
    struct leaf_0x10_3 {
    struct leaf_0x12_1 {
    struct leaf_0x12_2 {
    struct leaf_0x14_1 {
    struct leaf_0x17_1 {
    struct leaf_0x1d_1 {
    struct leaf_0x23_1 {
    struct leaf_0x23_3 {
    struct leaf_0x80000020_1 {
    struct leaf_0x80000020_2 {
    struct leaf_0x80000020_3 {

We do indeed have an encodings for leaves with large dynamic number of
valid subleaves, through "array=":

    darwi@lx ~/x86-cpuid-db (main)> git grep array=

    db/xml/leaf_04.xml:  <subleaf id="0" array="32">
    db/xml/leaf_0b.xml:  <subleaf id="0" array="2">
    db/xml/leaf_0d.xml:  <subleaf id="2" array="62">
    db/xml/leaf_10.xml:  <subleaf id="1" array="2">
    db/xml/leaf_12.xml:  <subleaf id="2" array="30">
    db/xml/leaf_17.xml:  <subleaf id="1" array="3">
    db/xml/leaf_18.xml:  <subleaf id="0" array="32">
    db/xml/leaf_1b.xml:  <subleaf id="0" array="32">
    db/xml/leaf_1f.xml:  <subleaf id="0" array="6">
    db/xml/leaf_8000001d.xml:  <subleaf id="0" array="32">
    db/xml/leaf_80000026.xml:  <subleaf id="0" array="4">

But the generators don't deal with that (yet), and that's why they're
also not in the generated CSV/header files.

I'm going through the Linux x86 PQ now, so it's a nice opportunity to
see how something like "struct leaf_0x0_0x0" looks within the rest of
the kernel code...  I'll also ping Thomas to see if he has any feedback
on the topic.

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH