linux-kernel - RE: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index

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:   Fri, 16 Apr 2021 17:58:48 +0000
From:   "K, Narendra" <Narendra.K@...l.com>
To:     Niklas Schnelle <schnelle@...ux.ibm.com>,
        Bjorn Helgaas <helgaas@...nel.org>
CC:     Viktor Mihajlovski <mihajlov@...ux.ibm.com>,
        Stefan Raspl <raspl@...ux.ibm.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        "linux-netdev@...r.kernel.org" <linux-netdev@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "K, Narendra" <Narendra.K@...l.com>
Subject: RE: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index

> -----Original Message-----
> From: Niklas Schnelle <schnelle@...ux.ibm.com>
> Sent: Thursday, April 15, 2021 12:55 PM
> To: Bjorn Helgaas
> Cc: K, Narendra; Viktor Mihajlovski; Stefan Raspl; Peter Oberparleiter; linux-
> netdev@...r.kernel.org; linux-pci@...r.kernel.org; linux-
> kernel@...r.kernel.org; linux-s390@...r.kernel.org
> Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
> 
> 
> [EXTERNAL EMAIL]
> 
> On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> > > On s390 each PCI device has a user-defined ID (UID) exposed under
> > > /sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the
> > > PCI device's primary index and to match the device within Linux to
> > > the device configured in the hypervisor. To serve as a primary
> > > identifier the UID must be unique within the Linux instance, this is
> > > guaranteed by the platform if and only if the UID Uniqueness
> > > Checking flag is set within the CLP List PCI Functions response.
> > >
> > > In this sense the UID serves an analogous function as the SMBIOS
> > > instance number or ACPI index exposed as the "index" respectively
> > > "acpi_index" device attributes and used by e.g. systemd to set
> > > interface names. As s390 does not use and will likely never use ACPI
> > > nor SMBIOS there is no conflict and we can just expose the UID under the
> "index"
> > > attribute whenever UID Uniqueness Checking is active and get
> > > systemd's interface naming support for free.
> > >
> > > Signed-off-by: Niklas Schnelle <schnelle@...ux.ibm.com>
> > > Acked-by: Viktor Mihajlovski <mihajlov@...ux.ibm.com>
> >
> > This seems like a nice solution to me.
> >
> > Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
> 
> Thanks! Yes I agree it's a simple solution that also makes sense from a design
> point. I'll wait for Narendra's opinion of course.

Hi Niklas,

It seems like the UID and the index are not equivalent in their meaning.

The index SMBIOS type 41 device type instance indicates that 

1. The device is an onboard device.
2. A specific order of the onboard devices.

The UID described seems to indicate that the PCI device is unique within the Linux instance (sufficient for naming). 
But it does not indicate that PCI device is onboard and any order. 

As all devices with UID will be named as eno<UID> (Ethernet onboard), names are not in sync with how each PCI function is exposed on a PCI slot (appears
closer to SMBIOS type 9 record) as described below.

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc

In summary, it seems like the eno<UID> names on s390 will be unique names, but may not match the meaning of the index.

Also,

a) Will UID remain unique/same as initially exposed across reboots ? 

b) Is the reuse of index related to the 'slots' based naming scheme described below ?   

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc

c) If the slot based naming is fixed with the naming scheme from changes below, any thoughts on why is reuse of index needed ? 

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc  

With regards,
Narendra K