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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvopvYGtqLzm5m4yhXLih7SuSSuw4RtRhBCiXob+rXsMP5fSA@mail.gmail.com>
Date: Wed, 17 Sep 2025 11:08:26 +0200
From: Matthew Wood <thepacketgeek@...il.com>
To: Krzysztof Wilczyński <kw@...ux.com>
Cc: Keith Busch <kbusch@...nel.org>, Bjorn Helgaas <helgaas@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Mario Limonciello <superm1@...nel.org>, 
	Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [RESEND PATCH v7 1/1] PCI/sysfs: Expose PCIe device serial number

Thank you all for the helpful responses!

> Hello,
>
> > > I can see that the PCI r3.0 (conventional PCI) spec doesn't include
> > > the Device Serial Number Capability and the PCIe spec does include it,
> > > but this seems like it would fit better in the pci_dev_dev_attrs[],
> > > and the visibility check would be parallel to the
> > > dev_attr_boot_vga.attr check there.
> >
> > I'm not sure I agree. The pci_dev_dev_attrs apply to all pci devices,
> > but DSN only exists in PCIe Extended Capability space. Conventional pci
> > config requests couldn't even describe it, so seems okay to fence it off
> > using the PCI-Express attribute group that already has that visibility
> > barrier.
>
> PCI-X 2.0 added Extended Configuration Space[1].  Perhaps why Bjorn had
> different attributes group in mind here.

Looking more at pci_get_dsn, I see that there's no check for pci_is_pcie so I
understand the thoughts here and can see how it would make sense to move
to pci_dev_dev_attrs.

I also agree that the visibility check for dsn would match the
existing dev_attr_boot_vga
check, with the additional advantage of not making the existing attrs in
pcie_dev_attrs_are_visible oddballs without visibility checks.

I will prepare a v8 with that change, thanks again!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ