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: <MN0PR11MB6010E31577416B56B708A3AFE0E4A@MN0PR11MB6010.namprd11.prod.outlook.com>
Date:   Fri, 1 Sep 2023 03:09:21 +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,

> Conceptually _all_ levels exist, but the ones which occupy zero bits have no meaning. Neither have the unknown levels if they should surface at some point.
>
> So as they _all_ exist the logical consequence is that even those which occupy zero bits have an ID.
>
> Code which is interested in information which depends on the enumeration of the level must obviously do:
>
>    if (level_exists(X))
>    	analyse_level(X)
>
> Whether you express that via an invalid level ID or via an explicit check for the level is an implementation detail.

Thank you for acknowledging that a level with a shift-width of 0 does not exist, and thus an id for that level has no meaning.

One could argue that except for package_id and core_id, which always exist, maintainable code would *always* check that a level exists before doing *anything* with its level_id.  Color me skeptical of an implementation that does otherwise...

So what are you proposing with the statement that "conceptually _all_ levels exist"?

> The problem of the current implementation is not that the die ID is automatically assigned. The problem is at the usage sites which blindly assume that there must be a meaning. That's a completely different issue and has absolutely nothing to do with purely mathematical deduced ID information at any given level.

I agree that the code that exports the die_id attributes in topology sysfs should not do so when the die_id is meaningless.

Thanks,
-Len

Ps. It is a safe bet that new levels will "surface at some point".  For example, DieGrp surfaced this summer w/o any prior consultation with the Linux team.  But even if they did consult us and gave us the ideal 1-year before-hardware advance notice, and even if we miraculously added support in 0 time, we would still be 2-years late to prescriptively recognize this new level -- as our enterprise customers routinely run 3-year-old kernels.  This is why it is mandatory that our code be resilient to the insertion of additional future levels.  I think it can be -- as long as we continue to use globally unique id's for all levels  (IIR, only core_id is not globally unique today) and do _nothing_ with levels that have a 0 shift-width.