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: <87r0nk66xl.ffs@tglx>
Date:   Wed, 30 Aug 2023 14:39:02 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Brown, Len" <len.brown@...el.com>,
        "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

On Wed, Aug 30 2023 at 02:46, Len Brown wrote:
>>    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.

Again. You are conflating an implementation detail with a conceptual
problem.

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.

Other code paths can still utilize the resulting ID for comparisons
without checking whether the level exists or not. The validity of such a
comparision is not per se wrong. It depends on what you want to achieve
and in some cases the unconditional comparison just allows you to write
better code because there are enough cases where the only information
required is whether two IDs are matching or not. Such code neither cares
whether there are multiple instances of that level nor does it deduce
that there is level dependent information.

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.

See?

Thanks,

        tglx