linux-kernel - RE: [patch V3 27/40] x86/cpu: Provide a sane leaf 0xb/0x1f parser

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: <MN0PR11MB6010F1D501B9A2C0B7B3D1F6E0E6A@MN0PR11MB6010.namprd11.prod.outlook.com>
Date:   Wed, 30 Aug 2023 02:46:20 +0000
From:   "Brown, Len" <len.brown@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "Gross, Jurgen" <jgross@...e.com>,
        "mikelley@...rosoft.com" <mikelley@...rosoft.com>,
        "arjan@...ux.intel.com" <arjan@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "ray.huang@....com" <ray.huang@....com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Sivanich, Dimitri" <dimitri.sivanich@....com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>
Subject: RE: [patch V3 27/40] x86/cpu: Provide a sane leaf 0xb/0x1f parser

Hello Thomas,

>    The way how 0x1F is designed and how the APIC ID space is
>    partitioned, makes it entirely clear that all domain levels must be
>    evaluated no matter what

Correct.

>    and it's more than obvious that
>    non-enumerated domain levels occupy _zero_ bits in the APIC ID
>    partitioning and therefore end up being size _one_.

By "size _one_", do you mean that a non-enumerated level gets a valid id, eg. id=0?

That direction would be problematic.

If CPUID.1F doesn't enumerate a module level, then there is NO module level.
Conjuring up a valid module_id=0 in this scenario is a bug.

For a module level to exist, it must occupy at least 1 bit in the APIC ID.

This is what I failed to impress upon you about die_id erroneously following the example of package_id.
Package_id is special.  There is always an architectural package, and if no package bits are set in the APIC-id, we can still assume package_id=0.

This is not true for the intermediate levels.  If they are not enumerated, they DO NOT EXIST.

This is particularly important given the ability of CPUID.1F to gain levels currently undocumented, and omit documented levels that may have no utility, or even a meaning, on future hardware.

-Len