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 10:49:32 -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 07:18:46PM +0100, Borislav Petkov wrote:
> On Mon, Jan 31, 2022 at 09:23:20AM -0800, Luck, Tony wrote:
> > 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.
> 
> Hmm, so we write that we don't really care about the physical socket in
> software:
> 
> Documentation/x86/topology.rst:
> "The kernel does not care about the concept of physical sockets because
> a socket has no relevance to software. It's an electromechanical
> component. In the past a socket always contained a single package
> (see below), but with the advent of Multi Chip Modules (MCM) a socket
> can hold more than one package. So there might be still references to
> sockets in the code, but they are of historical nature and should be
> cleaned up."
> 
> and the PPIN is a physical socket property. So there's no proper way for
> us to tie to anything that represents the physical socket.
> 
> So, the use case you're imagining would be, what?
> 
> The FRU code glue would go:
> 
> "I got an MCE on CPU X...
> 
> Lemme see which PPIN is it:
> 
> # cat /sys/devices/system/cpu/cpuX/topology/ppin
> BLA
> 
> ah ok, lemme report it:
> 
> You just had an MCE on CPU X, socket BLA"
> 
> Something like that?

Yes. We also have a new thing (patches coming soon) other than MCE
that would follow that same flow. So in general it is: "problem with CPU X,
go read the ppin file for that CPU to file the report".  For the new
thing, only root can trigger it, so not a problem for root to create
the report.

> But that FRU glue software would have to run as root so that it reads
> the ppin sysfs file.
> 
> But we don't want to expose that processor serial number to !root users
> so we're forcing the people to run the FRU thing as root.
> 
> This feels like this guy here:
> 
> https://c.tenor.com/fDZOE4okO3EAAAAC/homer-simpsons.gif

I think any paranoia about having a user readable "serial number"
should be gone by now. Those wacky web folks found a dozen different ways
to track your every move on the internet so that adverts for whatever
you just searched for will follow you for days. It seems highly
unlikely that browser writers will bother reading ppin and adding it
to cookies.

But I didn't want to get distracted by that, so made the file mode 0400.

-Tony