linux-kernel - Re: [PATCH v2 0/6] PPIN (Protected Processor Inventory Number) updates

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]

Date:   Mon, 31 Jan 2022 09:23:20 -0800
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Smita Koralahalli Channabasappa 
        <smita.koralahallichannabasappa@....com>,
        Wei Huang <wei.huang2@....com>,
        Tom Lendacky <thomas.lendacky@....com>, patches@...ts.linux.dev
Subject: Re: [PATCH v2 0/6] PPIN (Protected Processor Inventory Number)
 updates

On Mon, Jan 31, 2022 at 01:31:49PM +0100, Borislav Petkov wrote:
> On Fri, Jan 21, 2022 at 09:47:37AM -0800, Tony Luck wrote:
> > ...
> 
> They look good so far on my PPIN-enabled AMD box.
> 
> > 5) Add "ppin" to /sys/devices/system/cpu/cpu*/topology/ppin
> > 
> > The big question for this part is whether there is a better
> > place to expose this value. I'm open to other suggestions.
> 
> Yeah, I'm not sure about that either. I have
> 
> $ grep -r . /sys/devices/system/cpu/cpu*/topology/ppin | cut -d: -f 2 | uniq -c
>      32 0xxxxx
> 
> 32 times the same number.
> 
> Wouldn't
> 
> /sys/devices/system/node/
> 
> be a better place?

Maybe.

> Even if those were logical nodes, it would still be less needless
> replication and that would be one more way for root to figure out which
> logical nodes belong to the same physical package... :-)

That would work for existing products. There are some cases where
a single package appears as mutiple nodes. But that's ok ... as you
say, one more clue to the topology.

I'm worried that some future thing might reverse that and have
a "package" id for each die in a multi-die package which still
appears as a single node. That would distort the meaning of "package",
so it isn't supposed to happen. But if it did, Linux would be stuck
just reporting one of the "package" ids.

-Tony