From: Bjorn Helgaas <helgaas@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Leon Romanovsky" <leonro@nvidia.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, "Ariel Almog" <ariela@nvidia.com>,
"Aditya Prabhune" <aprabhune@nvidia.com>,
"Hannes Reinecke" <hare@suse.de>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Arun Easi" <aeasi@marvell.com>,
"Jonathan Chocron" <jonnyc@amazon.com>,
"Bert Kenward" <bkenward@solarflare.com>,
"Matt Carlson" <mcarlson@broadcom.com>,
"Kai-Heng Feng" <kai.heng.feng@canonical.com>,
"Jean Delvare" <jdelvare@suse.de>,
"Alex Williamson" <alex.williamson@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI/sysfs: Fix read permissions for VPD attributes
Date: Thu, 31 Oct 2024 18:22:52 -0500 [thread overview]
Message-ID: <20241031232252.GA1268406@bhelgaas> (raw)
In-Reply-To: <20241030000450.GA1180398@bhelgaas>
[+cc LKML etc, should PCI VPD be readable by non-root?]
On Tue, Oct 29, 2024 at 07:04:50PM -0500, Bjorn Helgaas wrote:
> On Mon, Oct 28, 2024 at 10:05:33AM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > The Virtual Product Data (VPD) attribute is not readable by regular
("Vital Product Data" is the term in the spec)
> > user without root permissions. Such restriction is not really needed,
> > as data presented in that VPD is not sensitive at all.
> >
> > This change aligns the permissions of the VPD attribute to be accessible
> > for read by all users, while write being restricted to root only.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: d93f8399053d ("PCI/sysfs: Convert "vpd" to static attribute")
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>
> Applied to pci/vpd for v6.13, thanks!
I think this deserves a little more consideration than I gave it
initially.
Obviously somebody is interested in using this; can we include some
examples so we know there's an actual user?
Are we confident that VPD never contains anything sensitive? It may
contain arbitrary vendor-specific information, so we can't know what
might be in that part.
Reading VPD is fairly complicated and we've had problems in the past
(we have quirk_blacklist_vpd() for devices that behave
"unpredictably"), so it's worth considering whether allowing non-root
to do this could be exploited or could allow DOS attacks.
For reference, here are the fields defined in PCIe r6.0, sec 6.27.2
(although VPD can contain anything a manufacturer wants to put there):
PN Add-in Card Part Number
EC Engineering Change Level of the Add-in Card
FG Fabric Geography
LC Location
MN Manufacture ID
PG PCI Geography
SN Serial Number
TR Thermal Reporting
Vx Vendor Specific
CP Extended Capability
RV Checksum and Reserved
FF Form Factor
Yx System Specific
YA Asset Tag Identifier
RW Remaining Read/Write Area
The Conventional PCI spec, r3.0, sec 6.4, says:
Vital Product Data (VPD) is the information that uniquely defines
items such as the hardware, software, and microcode elements of a
system. The VPD provides the system with information on various FRUs
(Field Replaceable Unit) including Part Number, Serial Number, and
other detailed information. VPD also provides a mechanism for
storing information such as performance and failure data on the
device being monitored. The objective, from a system point of view,
is to collect this information by reading it from the hardware,
software, and microcode components.
Some of that, e.g., performance and failure data, might be considered
sensitive in some environments.
> > ---
> > I added stable@ as it was discovered during our hardware ennoblement
> > and it is important to be picked by distributions too.
> > ---
> > drivers/pci/vpd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> > index e4300f5f304f..2537685cac90 100644
> > --- a/drivers/pci/vpd.c
> > +++ b/drivers/pci/vpd.c
> > @@ -317,7 +317,7 @@ static ssize_t vpd_write(struct file *filp, struct kobject *kobj,
> >
> > return ret;
> > }
> > -static BIN_ATTR(vpd, 0600, vpd_read, vpd_write, 0);
> > +static BIN_ATTR_RW(vpd, 0);
> >
> > static struct bin_attribute *vpd_attrs[] = {
> > &bin_attr_vpd,
> > --
> > 2.46.2
> >
next prev parent reply other threads:[~2024-10-31 23:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 8:05 [PATCH] PCI/sysfs: Fix read permissions for VPD attributes Leon Romanovsky
2024-10-30 0:04 ` Bjorn Helgaas
2024-10-31 23:22 ` Bjorn Helgaas [this message]
2024-11-01 14:33 ` Leon Romanovsky
2024-11-01 16:47 ` Bjorn Helgaas
2024-11-03 12:33 ` Leon Romanovsky
2024-11-05 0:10 ` Bjorn Helgaas
2024-11-05 7:51 ` Leon Romanovsky
2024-11-05 15:24 ` Bjorn Helgaas
2024-11-05 16:26 ` Leon Romanovsky
2024-11-07 11:31 ` Leon Romanovsky
2024-11-07 14:59 ` Bjorn Helgaas
2024-11-07 16:15 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241031232252.GA1268406@bhelgaas \
--to=helgaas@kernel.org \
--cc=aeasi@marvell.com \
--cc=alex.williamson@redhat.com \
--cc=aprabhune@nvidia.com \
--cc=ariela@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bkenward@solarflare.com \
--cc=hare@suse.de \
--cc=hkallweit1@gmail.com \
--cc=jdelvare@suse.de \
--cc=jonnyc@amazon.com \
--cc=kai.heng.feng@canonical.com \
--cc=kw@linux.com \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mcarlson@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox