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

[Borislav Petkov <bp@alien8.de>]

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?

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

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette