Fix read permissions for VPD attributes
Subsystems (4)
cover Fix read permissions for VPD attributes
From: Leon Romanovsky <[email protected]>
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(-)
Signature · 1 line
2.47.0
PATCH 1/2 PCI/sysfs: Change read permissions for VPD attributes
From: Leon Romanovsky <[email protected]>
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.
--- drivers/pci/vpd.c | 9 ++++++++- include/linux/pci.h | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-)
drivers/pci/vpd.c +8 -1
@@ -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,
include/linux/pci.h +6 -1
@@ -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) \
Signature · 1 line
2.47.0
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
Quoted 7 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 5 lines
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.
Quoted 68 lines
Signed-off-by Leon Romanovsky <[email protected]>--- drivers/pci/vpd.c | 9 ++++++++- include/linux/pci.h | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-)drivers/pci/vpd.c +8
-1@@ -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,include/linux/pci.h +6
-1@@ -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) \Signature · 1 line
2.47.0
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
Quoted 8 lines · Bjorn Helgaas
Quoted 7 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 69 lines
Quoted 69 lines
Signed-off-by Leon Romanovsky <[email protected]>--- drivers/pci/vpd.c | 9 ++++++++- include/linux/pci.h | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-)drivers/pci/vpd.c +8
-1@@ -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,include/linux/pci.h +6
-1@@ -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) \Signature · 1 line
2.47.0
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
[+cc Thomas]
Quoted 15 lines · Leon Romanovsky
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 7 lines
Quoted 2 lines
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.
Avoiding root/setuid is a very good thing. I just don't think using VPD directly from userspace is a great idea because VPD is so slow and sometimes unreliable to read. And apparently this is a pretty unusual situation since I haven't heard similar requests for other devices.
Sort of ironic that some vendors, especially Intel and AMD, add new Device IDs for devices that work exactly the same as their predecessors, so we are continually adding to the pci_device_id tables, while here we apparently the same Device ID is used for devices that differ in ways we actually want to know about.
Quoted 8 lines
Quoted 2 lines
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.
To me it looks like a pci_dev bit, not a pci_driver bit.
I would set it .probe() so all the code is in one place. And it's not related to a device defect, as most quirks are.
Bjorn
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
Quoted 21 lines · Bjorn Helgaas
[+cc Thomas]
Quoted 18 lines · Leon Romanovsky
Quoted 16 lines · Bjorn Helgaas
Quoted 7 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 5 lines
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).
Quoted 8 lines
Quoted 4 lines
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.
Avoiding root/setuid is a very good thing. I just don't think using VPD directly from userspace is a great idea because VPD is so slow and sometimes unreliable to read.
This is one time operation during application initialization, which is
fast in our devices. It is used by the NVML https://developer.nvidia.com/management-library-nvml.
Quoted 2 lines
And apparently this is a pretty unusual situation since I haven't heard similar requests for other devices.
Maybe they didn't bother to ask.
Quoted 6 lines
Sort of ironic that some vendors, especially Intel and AMD, add new Device IDs for devices that work exactly the same as their predecessors, so we are continually adding to the
pci_device_idtables, while here we apparently the same Device ID is used for devices that differ in ways we actually want to know about.
I'm not Intel or AMD employee and never worked there, but from what I heard it is not technical decision but outcome of how their development process is structured.
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
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.
Quoted 4 lines
To me it looks like a
pci_devbit, not apci_driverbit.I would set it .probe() so all the code is in one place. And it's not related to a device defect, as most quirks are.
The advantage of quirks is that we will be able to set proper file permissions from the beginning without need to load/bind driver.
As Thomas suggested, the vpd_attr_is_visible() will be something like this, which is neat:
if (pdev->downgrade_vpd_read)
return 644; else return 600;
Thanks
Quoted 3 lines
Bjorn
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
In reply to Bjorn HelgaasQuoted 11 lines · On Mon, 11 Nov 2024 14:41:04 -0600 Bjorn Helgaas <[email protected]> wrote:
Quoted 10 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 17 lines · Stephen Hemminger
Quoted 14 lines · On Mon, 11 Nov 2024 14:41:04 -0600 Bjorn Helgaas <[email protected]> wrote:
Quoted 12 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 7 lines
Quoted 5 lines
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
In reply to Stephen HemmingerQuoted 17 lines · Stephen Hemminger
Quoted 14 lines · On Mon, 11 Nov 2024 14:41:04 -0600 Bjorn Helgaas <[email protected]> wrote:
Quoted 12 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 8 lines
Quoted 5 lines
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
Quoted 27 lines · Heiner Kallweit
Quoted 17 lines · Stephen Hemminger
Quoted 14 lines · On Mon, 11 Nov 2024 14:41:04 -0600 Bjorn Helgaas <[email protected]> wrote:
Quoted 12 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 7 lines
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?
Quoted 1 line
Re: [PATCH v1 1/2] PCI/sysfs: Change read permissions for VPD attributes
Quoted 36 lines · Leon Romanovsky
Quoted 27 lines · Heiner Kallweit
Quoted 17 lines · Stephen Hemminger
Quoted 14 lines · On Mon, 11 Nov 2024 14:41:04 -0600 Bjorn Helgaas <[email protected]> wrote:
Quoted 12 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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?
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
In reply to Leon RomanovskyQuoted 32 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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 <[email protected]>--- drivers/pci/vpd.c | 9 ++++++++- include/linux/pci.h | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-)drivers/pci/vpd.c +1
-0@@ -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;
drivers/pci/vpd.c static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count, · line 175
Quoted 8 lines
drivers/pci/vpd.c +5
-0@@ -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.
Quoted 41 lines
drivers/pci/vpd.c +2
-1+ 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,include/linux/pci.h +6
-1@@ -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) \Signature · 1 line
2.47.0
PATCH 2/2 net/mlx5: Enable unprivileged read of PCI VPD file
In reply to Leon RomanovskyFrom: Leon Romanovsky <[email protected]>
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
--- drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlx5/core/main.c +1 -0
@@ -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, };/**
Signature · 1 line
2.47.0
Re: [PATCH v1 2/2] net/mlx5: Enable unprivileged read of PCI VPD file
Quoted 5 lines · On Thu, 7 Nov 2024 20:56:57 +0200 Leon Romanovsky wrote:
From: Leon Romanovsky <[email protected]>
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.
Quoted 17 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
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
Quoted 8 lines
Leon Romanovsky (2):
PCI/sysfs: Change read permissions for VPD attributes net/mlx5: Enable unprivileged read of PCI VPD filedrivers/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
Quoted 5 lines
Signature · 2 lines
-- 2.47.0