[PATCH v1 0/2] Fix read permissions for VPD attributes

[PATCH v1 0/2] Fix read permissions for VPD attributes

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

Changelog:
v1: 
 * Changed implementation from open-read-to-everyone to be opt-in
 * Removed stable and Fixes tags, as it seems like feature now.
v0: https://lore.kernel.org/all/65791906154e3e5ea12ea49127cf7c707325ca56.1730102428.git.leonro@nvidia.com/

--------------------------------------------------------------------------
Hi,

The Vital Product Data (VPD) sysfs file is not readable by unprivileged
users. This limitation is not necessary and can be removed at least for
devices which are known as safe.

Thanks

Leon Romanovsky (2):
  PCI/sysfs: Change read permissions for VPD attributes
  net/mlx5: Enable unprivileged read of PCI VPD file

 drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
 drivers/pci/vpd.c                              | 9 ++++++++-
 include/linux/pci.h                            | 7 ++++++-
 3 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.47.0

[PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

The Vital Product Data (VPD) attribute is not readable by regular
user without root permissions. Such restriction is not really needed
for many devices in the world, as data presented in that VPD is not
sensitive and access to the HW is safe and tested.

This change aligns the permissions of the VPD attribute to be accessible
for read by all users, while write being restricted to root only.

For the driver, there is a need to opt-in in order to allow this
functionality.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/pci/vpd.c   | 9 ++++++++-
 include/linux/pci.h | 7 ++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index e4300f5f304f..7c70930abaa0 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -156,6 +156,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 			    void *arg, bool check_size)
 {
 	struct pci_vpd *vpd = &dev->vpd;
+	struct pci_driver *drv;
 	unsigned int max_len;
 	int ret = 0;
 	loff_t end = pos + count;
@@ -167,6 +168,12 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	if (pos < 0)
 		return -EINVAL;
 
+	if (!capable(CAP_SYS_ADMIN)) {
+		drv = to_pci_driver(dev->dev.driver);
+		if (!drv || !drv->downgrade_vpd_read)
+			return -EPERM;
+	}
+
 	max_len = check_size ? vpd->len : PCI_VPD_MAX_SIZE;
 
 	if (pos >= max_len)
@@ -317,7 +324,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,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 573b4c4c2be6..b8fed74e742e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -943,6 +943,10 @@ struct module;
  *		how to manage the DMA themselves and set this flag so that
  *		the IOMMU layer will allow them to setup and manage their
  *		own I/O address space.
+ * @downgrade_vpd_read: Device doesn't require root permissions from the users
+ *              to read VPD information. The driver doesn't expose any sensitive
+ *              information through that interface and safe to be accessed by
+ *              unprivileged users.
  */
 struct pci_driver {
 	const char		*name;
@@ -960,7 +964,8 @@ struct pci_driver {
 	const struct attribute_group **dev_groups;
 	struct device_driver	driver;
 	struct pci_dynids	dynids;
-	bool driver_managed_dma;
+	bool driver_managed_dma : 1;
+	bool downgrade_vpd_read : 1;
 };
 
 #define to_pci_driver(__drv)	\
-- 
2.47.0

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Bjorn Helgaas]

On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> The Vital Product Data (VPD) attribute is not readable by regular
> user without root permissions. Such restriction is not really needed
> for many devices in the world, as data presented in that VPD is not
> sensitive and access to the HW is safe and tested.
> 
> This change aligns the permissions of the VPD attribute to be accessible
> for read by all users, while write being restricted to root only.
> 
> For the driver, there is a need to opt-in in order to allow this
> functionality.

I don't think the use case is very strong (and not included at all
here).

If we do need to do this, I think it's a property of the device, not
the driver.

> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
>  drivers/pci/vpd.c   | 9 ++++++++-
>  include/linux/pci.h | 7 ++++++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> index e4300f5f304f..7c70930abaa0 100644
> --- a/drivers/pci/vpd.c
> +++ b/drivers/pci/vpd.c
> @@ -156,6 +156,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  			    void *arg, bool check_size)
>  {
>  	struct pci_vpd *vpd = &dev->vpd;
> +	struct pci_driver *drv;
>  	unsigned int max_len;
>  	int ret = 0;
>  	loff_t end = pos + count;
> @@ -167,6 +168,12 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  	if (pos < 0)
>  		return -EINVAL;
>  
> +	if (!capable(CAP_SYS_ADMIN)) {
> +		drv = to_pci_driver(dev->dev.driver);
> +		if (!drv || !drv->downgrade_vpd_read)
> +			return -EPERM;
> +	}
> +
>  	max_len = check_size ? vpd->len : PCI_VPD_MAX_SIZE;
>  
>  	if (pos >= max_len)
> @@ -317,7 +324,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,
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 573b4c4c2be6..b8fed74e742e 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -943,6 +943,10 @@ struct module;
>   *		how to manage the DMA themselves and set this flag so that
>   *		the IOMMU layer will allow them to setup and manage their
>   *		own I/O address space.
> + * @downgrade_vpd_read: Device doesn't require root permissions from the users
> + *              to read VPD information. The driver doesn't expose any sensitive
> + *              information through that interface and safe to be accessed by
> + *              unprivileged users.
>   */
>  struct pci_driver {
>  	const char		*name;
> @@ -960,7 +964,8 @@ struct pci_driver {
>  	const struct attribute_group **dev_groups;
>  	struct device_driver	driver;
>  	struct pci_dynids	dynids;
> -	bool driver_managed_dma;
> +	bool driver_managed_dma : 1;
> +	bool downgrade_vpd_read : 1;
>  };
>  
>  #define to_pci_driver(__drv)	\
> -- 
> 2.47.0
> 

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Leon Romanovsky]

On Mon, Nov 11, 2024 at 02:41:04PM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > The Vital Product Data (VPD) attribute is not readable by regular
> > user without root permissions. Such restriction is not really needed
> > for many devices in the world, as data presented in that VPD is not
> > sensitive and access to the HW is safe and tested.
> > 
> > This change aligns the permissions of the VPD attribute to be accessible
> > for read by all users, while write being restricted to root only.
> > 
> > For the driver, there is a need to opt-in in order to allow this
> > functionality.
> 
> I don't think the use case is very strong (and not included at all
> here).

I will add the use case, which is running monitoring application without
need to be root. IMHO reducing number of applications that require
privileged access is a very strong case. I personally try to avoid
applications with root/setuid privileges.

> 
> If we do need to do this, I think it's a property of the device, not
> the driver.

But how will device inform PCI core about safe VPD read?
Should I add new field to struct pci_device_id? Add a quirk?
Otherwise, I will need to add a line "pci_dev->downgrade_vpd_read=true"
to mlx5 probe function and it won't change a lot from current
implementation.

> 
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> >  drivers/pci/vpd.c   | 9 ++++++++-
> >  include/linux/pci.h | 7 ++++++-
> >  2 files changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> > index e4300f5f304f..7c70930abaa0 100644
> > --- a/drivers/pci/vpd.c
> > +++ b/drivers/pci/vpd.c
> > @@ -156,6 +156,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
> >  			    void *arg, bool check_size)
> >  {
> >  	struct pci_vpd *vpd = &dev->vpd;
> > +	struct pci_driver *drv;
> >  	unsigned int max_len;
> >  	int ret = 0;
> >  	loff_t end = pos + count;
> > @@ -167,6 +168,12 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
> >  	if (pos < 0)
> >  		return -EINVAL;
> >  
> > +	if (!capable(CAP_SYS_ADMIN)) {
> > +		drv = to_pci_driver(dev->dev.driver);
> > +		if (!drv || !drv->downgrade_vpd_read)
> > +			return -EPERM;
> > +	}
> > +
> >  	max_len = check_size ? vpd->len : PCI_VPD_MAX_SIZE;
> >  
> >  	if (pos >= max_len)
> > @@ -317,7 +324,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,
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 573b4c4c2be6..b8fed74e742e 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -943,6 +943,10 @@ struct module;
> >   *		how to manage the DMA themselves and set this flag so that
> >   *		the IOMMU layer will allow them to setup and manage their
> >   *		own I/O address space.
> > + * @downgrade_vpd_read: Device doesn't require root permissions from the users
> > + *              to read VPD information. The driver doesn't expose any sensitive
> > + *              information through that interface and safe to be accessed by
> > + *              unprivileged users.
> >   */
> >  struct pci_driver {
> >  	const char		*name;
> > @@ -960,7 +964,8 @@ struct pci_driver {
> >  	const struct attribute_group **dev_groups;
> >  	struct device_driver	driver;
> >  	struct pci_dynids	dynids;
> > -	bool driver_managed_dma;
> > +	bool driver_managed_dma : 1;
> > +	bool downgrade_vpd_read : 1;
> >  };
> >  
> >  #define to_pci_driver(__drv)	\
> > -- 
> > 2.47.0
> > 

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Stephen Hemminger]

On Mon, 11 Nov 2024 14:41:04 -0600
Bjorn Helgaas <helgaas@kernel.org> wrote:

> On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > The Vital Product Data (VPD) attribute is not readable by regular
> > user without root permissions. Such restriction is not really needed
> > for many devices in the world, as data presented in that VPD is not
> > sensitive and access to the HW is safe and tested.
> > 
> > This change aligns the permissions of the VPD attribute to be accessible
> > for read by all users, while write being restricted to root only.
> > 
> > For the driver, there is a need to opt-in in order to allow this
> > functionality.  
> 
> I don't think the use case is very strong (and not included at all
> here).
> 
> If we do need to do this, I think it's a property of the device, not
> the driver.

I remember some broken PCI devices, which will crash if VPD is read.
Probably not worth opening this can of worms.

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Leon Romanovsky]

On Mon, Nov 11, 2024 at 04:34:30PM -0800, Stephen Hemminger wrote:
> On Mon, 11 Nov 2024 14:41:04 -0600
> Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
> > On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@nvidia.com>
> > > 
> > > The Vital Product Data (VPD) attribute is not readable by regular
> > > user without root permissions. Such restriction is not really needed
> > > for many devices in the world, as data presented in that VPD is not
> > > sensitive and access to the HW is safe and tested.
> > > 
> > > This change aligns the permissions of the VPD attribute to be accessible
> > > for read by all users, while write being restricted to root only.
> > > 
> > > For the driver, there is a need to opt-in in order to allow this
> > > functionality.  
> > 
> > I don't think the use case is very strong (and not included at all
> > here).
> > 
> > If we do need to do this, I think it's a property of the device, not
> > the driver.
> 
> I remember some broken PCI devices, which will crash if VPD is read.

This is opt-in feature for devices which are known to be working.
Broken devices will continue to be broken and will continue to require
root permissions for read.

Thanks

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Heiner Kallweit]

On 12.11.2024 01:34, Stephen Hemminger wrote:
> On Mon, 11 Nov 2024 14:41:04 -0600
> Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
>> On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>>>
>>> The Vital Product Data (VPD) attribute is not readable by regular
>>> user without root permissions. Such restriction is not really needed
>>> for many devices in the world, as data presented in that VPD is not
>>> sensitive and access to the HW is safe and tested.
>>>
>>> This change aligns the permissions of the VPD attribute to be accessible
>>> for read by all users, while write being restricted to root only.
>>>
>>> For the driver, there is a need to opt-in in order to allow this
>>> functionality.  
>>
>> I don't think the use case is very strong (and not included at all
>> here).
>>
>> If we do need to do this, I think it's a property of the device, not
>> the driver.
> 
> I remember some broken PCI devices, which will crash if VPD is read.
> Probably not worth opening this can of worms.

These crashes shouldn't occur any longer. There are two problematic cases:
1. Reading past end of VPD
   This used to crash certain devices and was fixed by stop reading at
   the VPD end tag.
2. Accessing VPD if device firmware isn't correctly loaded and initialized
   This affects certain LSI devices, which are blacklisted so that PCI core
   prevents VPD access.

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Leon Romanovsky]

On Tue, Nov 12, 2024 at 07:44:09AM +0100, Heiner Kallweit wrote:
> On 12.11.2024 01:34, Stephen Hemminger wrote:
> > On Mon, 11 Nov 2024 14:41:04 -0600
> > Bjorn Helgaas <helgaas@kernel.org> wrote:
> > 
> >> On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> >>> From: Leon Romanovsky <leonro@nvidia.com>
> >>>
> >>> The Vital Product Data (VPD) attribute is not readable by regular
> >>> user without root permissions. Such restriction is not really needed
> >>> for many devices in the world, as data presented in that VPD is not
> >>> sensitive and access to the HW is safe and tested.
> >>>
> >>> This change aligns the permissions of the VPD attribute to be accessible
> >>> for read by all users, while write being restricted to root only.
> >>>
> >>> For the driver, there is a need to opt-in in order to allow this
> >>> functionality.  
> >>
> >> I don't think the use case is very strong (and not included at all
> >> here).
> >>
> >> If we do need to do this, I think it's a property of the device, not
> >> the driver.
> > 
> > I remember some broken PCI devices, which will crash if VPD is read.
> > Probably not worth opening this can of worms.
> 
> These crashes shouldn't occur any longer. There are two problematic cases:
> 1. Reading past end of VPD
>    This used to crash certain devices and was fixed by stop reading at
>    the VPD end tag.
> 2. Accessing VPD if device firmware isn't correctly loaded and initialized
>    This affects certain LSI devices, which are blacklisted so that PCI core
>    prevents VPD access.

Thanks for the information.

Bjorn,

After this response, do you still think that v0 [1] is not the right way
to change the read permission?

[1] https://lore.kernel.org/all/65791906154e3e5ea12ea49127cf7c707325ca56.1730102428.git.leonro@nvidia.com/

> 

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 09:26:04AM +0200, Leon Romanovsky wrote:
> On Tue, Nov 12, 2024 at 07:44:09AM +0100, Heiner Kallweit wrote:
> > On 12.11.2024 01:34, Stephen Hemminger wrote:
> > > On Mon, 11 Nov 2024 14:41:04 -0600
> > > Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > 
> > >> On Thu, Nov 07, 2024 at 08:56:56PM +0200, Leon Romanovsky wrote:
> > >>> From: Leon Romanovsky <leonro@nvidia.com>
> > >>>
> > >>> The Vital Product Data (VPD) attribute is not readable by regular
> > >>> user without root permissions. Such restriction is not really needed
> > >>> for many devices in the world, as data presented in that VPD is not
> > >>> sensitive and access to the HW is safe and tested.
> > >>>
> > >>> This change aligns the permissions of the VPD attribute to be accessible
> > >>> for read by all users, while write being restricted to root only.
> > >>>
> > >>> For the driver, there is a need to opt-in in order to allow this
> > >>> functionality.  
> > >>
> > >> I don't think the use case is very strong (and not included at all
> > >> here).
> > >>
> > >> If we do need to do this, I think it's a property of the device, not
> > >> the driver.
> > > 
> > > I remember some broken PCI devices, which will crash if VPD is read.
> > > Probably not worth opening this can of worms.
> > 
> > These crashes shouldn't occur any longer. There are two problematic cases:
> > 1. Reading past end of VPD
> >    This used to crash certain devices and was fixed by stop reading at
> >    the VPD end tag.
> > 2. Accessing VPD if device firmware isn't correctly loaded and initialized
> >    This affects certain LSI devices, which are blacklisted so that PCI core
> >    prevents VPD access.
> 
> Thanks for the information.
> 
> Bjorn,
> 
> After this response, do you still think that v0 [1] is not the right way
> to change the read permission?
> 
> [1] https://lore.kernel.org/all/65791906154e3e5ea12ea49127cf7c707325ca56.1730102428.git.leonro@nvidia.com/

Yes, I still think it's unnecessarily risky to make VPD readable
by ordinary users.  This is a pretty niche use case.

Bjorn

Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes

[Thomas Weißschuh]

On 2024-11-07 20:56:56+0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> The Vital Product Data (VPD) attribute is not readable by regular
> user without root permissions. Such restriction is not really needed
> for many devices in the world, as data presented in that VPD is not
> sensitive and access to the HW is safe and tested.
> 
> This change aligns the permissions of the VPD attribute to be accessible
> for read by all users, while write being restricted to root only.
> 
> For the driver, there is a need to opt-in in order to allow this
> functionality.
> 
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
>  drivers/pci/vpd.c   | 9 ++++++++-
>  include/linux/pci.h | 7 ++++++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> index e4300f5f304f..7c70930abaa0 100644
> --- a/drivers/pci/vpd.c
> +++ b/drivers/pci/vpd.c
> @@ -156,6 +156,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  			    void *arg, bool check_size)
>  {
>  	struct pci_vpd *vpd = &dev->vpd;
> +	struct pci_driver *drv;
>  	unsigned int max_len;
>  	int ret = 0;
>  	loff_t end = pos + count;
> @@ -167,6 +168,12 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  	if (pos < 0)
>  		return -EINVAL;
>  
> +	if (!capable(CAP_SYS_ADMIN)) {
> +		drv = to_pci_driver(dev->dev.driver);
> +		if (!drv || !drv->downgrade_vpd_read)
> +			return -EPERM;
> +	}

If you move the check into vpd_attr_is_visible() then the sysfs core
will enforce the permissions and it's obvious for the user if they can
or can't read/write the file.

> +
>  	max_len = check_size ? vpd->len : PCI_VPD_MAX_SIZE;
>  
>  	if (pos >= max_len)
> @@ -317,7 +324,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,
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 573b4c4c2be6..b8fed74e742e 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -943,6 +943,10 @@ struct module;
>   *		how to manage the DMA themselves and set this flag so that
>   *		the IOMMU layer will allow them to setup and manage their
>   *		own I/O address space.
> + * @downgrade_vpd_read: Device doesn't require root permissions from the users
> + *              to read VPD information. The driver doesn't expose any sensitive
> + *              information through that interface and safe to be accessed by
> + *              unprivileged users.
>   */
>  struct pci_driver {
>  	const char		*name;
> @@ -960,7 +964,8 @@ struct pci_driver {
>  	const struct attribute_group **dev_groups;
>  	struct device_driver	driver;
>  	struct pci_dynids	dynids;
> -	bool driver_managed_dma;
> +	bool driver_managed_dma : 1;
> +	bool downgrade_vpd_read : 1;
>  };
>  
>  #define to_pci_driver(__drv)	\
> -- 
> 2.47.0
> 

[PATCH v1 2/2] net/mlx5: Enable unprivileged read of PCI VPD file

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

mlx5 devices are PCIe spec compliant, doesn't expose any sensitive
information Vital Product Data (VPD) section. In addition, these devices
are capable to provide an unprivileged read access file exposed by PCI core.

The parsed VPD section looks like this:
08:00.0 Ethernet controller: Mellanox Technologies MT2910 Family
[ConnectX-7]
...
  Capabilities: [48] Vital Product Data
    Product Name: NVIDIA ConnectX-7 HHHL adapter Card, 200GbE / NDR200 IB, Dual-port QSFP112, PCIe 5.0 x16 with x16 PCIe
extension option, Crypto, Secure Boot Capable
    Read-only fields:
        [PN] Part number: MCX713106AEHEA_QP1
        [EC] Engineering changes: A5
        [V2] Vendor specific: MCX713106AEHEA_QP1
        [SN] Serial number: MT2314XZ0JUZ
        [V3] Vendor specific: 0a5efb8958deed118000946dae7db798
        [VA] Vendor specific: MLX:MN=MLNX:CSKU=V2:UUID=V3:PCI=V0:MODL=CX713106A
        [V0] Vendor specific: PCIeGen5 x16
        [VU] Vendor specific: MT2314XZ0JUZMLNXS0D0F0
        [RV] Reserved: checksum good, 1 byte(s) reserved
    End

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 220a9ac75c8b..7e34badd174b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -2280,6 +2280,7 @@ static struct pci_driver mlx5_core_driver = {
 	.sriov_configure   = mlx5_core_sriov_configure,
 	.sriov_get_vf_total_msix = mlx5_sriov_get_vf_total_msix,
 	.sriov_set_msix_vec_count = mlx5_core_sriov_set_msix_vec_count,
+	.downgrade_vpd_read = true,
 };
 
 /**
-- 
2.47.0

Re: [PATCH v1 2/2] net/mlx5: Enable unprivileged read of PCI VPD file

[Jakub Kicinski]

On Thu,  7 Nov 2024 20:56:57 +0200 Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> mlx5 devices are PCIe spec compliant, doesn't expose any sensitive
> information Vital Product Data (VPD) section. In addition, these devices
> are capable to provide an unprivileged read access file exposed by PCI core.

Acked-by: Jakub Kicinski <kuba@kernel.org>

Re: [PATCH v1 0/2] Fix read permissions for VPD attributes

[Leon Romanovsky]

On Thu, Nov 07, 2024 at 08:56:55PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> Changelog:
> v1: 
>  * Changed implementation from open-read-to-everyone to be opt-in
>  * Removed stable and Fixes tags, as it seems like feature now.
> v0: https://lore.kernel.org/all/65791906154e3e5ea12ea49127cf7c707325ca56.1730102428.git.leonro@nvidia.com/
> 
> --------------------------------------------------------------------------
> Hi,
> 
> The Vital Product Data (VPD) sysfs file is not readable by unprivileged
> users. This limitation is not necessary and can be removed at least for
> devices which are known as safe.
> 
> Thanks
> 
> Leon Romanovsky (2):
>   PCI/sysfs: Change read permissions for VPD attributes
>   net/mlx5: Enable unprivileged read of PCI VPD file
> 
>  drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
>  drivers/pci/vpd.c                              | 9 ++++++++-
>  include/linux/pci.h                            | 7 ++++++-
>  3 files changed, 15 insertions(+), 2 deletions(-)

Bjorn,

Does this version resolve your concerns about broken devices in the field?

Thanks

> 
> -- 
> 2.47.0
> 
>