Re: [PATCH v2 2/5] vfio/pci: Add device blocklist
On Wed, Jul 22, 2020 at 11:02:10PM -0600, Alex Williamson wrote: > On Tue, 14 Jul 2020 07:36:07 +0100 > Giovanni Cabiddu wrote: > > > Add blocklist of devices that by default are not probed by vfio-pci. > > Devices in this list may be susceptible to untrusted application, even > > if the IOMMU is enabled. To be accessed via vfio-pci, the user has to > > explicitly disable the blocklist. > > > > The blocklist can be disabled via the module parameter disable_blocklist. > > > > Signed-off-by: Giovanni Cabiddu > > --- > > drivers/vfio/pci/vfio_pci.c | 33 + > > 1 file changed, 33 insertions(+) > > Hi Giovanni, > > I'm pretty satisfied with this series, except "blocklist" makes me > think of block devices, ie. storage, or block chains, or building block > types of things before I get to "block" as in a barrier. The other > alternative listed as a suggestion currently in linux-next is denylist, > which is the counter to an allowlist. I've already proposed changing > some other terminology in vfio.c to use the term "allowed", so > allow/deny would be my preference versus pass/block. Thanks Alex for your feedback. A new revision is on the way. Regards, -- Giovanni
Re: [PATCH v2 2/5] vfio/pci: Add device blocklist
On Tue, 14 Jul 2020 07:36:07 +0100
Giovanni Cabiddu wrote:
> Add blocklist of devices that by default are not probed by vfio-pci.
> Devices in this list may be susceptible to untrusted application, even
> if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
> explicitly disable the blocklist.
>
> The blocklist can be disabled via the module parameter disable_blocklist.
>
> Signed-off-by: Giovanni Cabiddu
> ---
> drivers/vfio/pci/vfio_pci.c | 33 +
> 1 file changed, 33 insertions(+)
Hi Giovanni,
I'm pretty satisfied with this series, except "blocklist" makes me
think of block devices, ie. storage, or block chains, or building block
types of things before I get to "block" as in a barrier. The other
alternative listed as a suggestion currently in linux-next is denylist,
which is the counter to an allowlist. I've already proposed changing
some other terminology in vfio.c to use the term "allowed", so
allow/deny would be my preference versus pass/block.
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 7c0779018b1b..ea5904ca6cbf 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -60,6 +60,10 @@ module_param(enable_sriov, bool, 0644);
> MODULE_PARM_DESC(enable_sriov, "Enable support for SR-IOV configuration.
> Enabling SR-IOV on a PF typically requires support of the userspace PF
> driver, enabling VFs without such support may result in non-functional VFs or
> PF.");
> #endif
>
> +static bool disable_blocklist;
> +module_param(disable_blocklist, bool, 0444);
> +MODULE_PARM_DESC(disable_blocklist, "Disable device blocklist. If set, i.e.
> blocklist disabled, then blocklisted devices are allowed to be probed by
> vfio-pci.");
This seems a little obtuse, could we expand a bit to allow users to
understand why a device might be on the denylist? Ex:
"Disable use of device denylist, which prevents binding to device with
known errata that may lead to exploitable stability or security issues
when accessed by untrusted users."
I think that more properly sets expectations when a device is denied
via this list and the admin looks to see how they might workaround it.
> +
> static inline bool vfio_vga_disabled(void)
> {
> #ifdef CONFIG_VFIO_PCI_VGA
> @@ -69,6 +73,29 @@ static inline bool vfio_vga_disabled(void)
> #endif
> }
>
> +static bool vfio_pci_dev_in_blocklist(struct pci_dev *pdev)
> +{
> + return false;
> +}
> +
> +static bool vfio_pci_is_blocklisted(struct pci_dev *pdev)
> +{
> + if (!vfio_pci_dev_in_blocklist(pdev))
> + return false;
> +
> + if (disable_blocklist) {
> + pci_warn(pdev,
> + "device blocklist disabled - allowing device
> %04x:%04x.\n",
Here we even use "allowing" to describe what happens when the blocklist
is disabled, "deny" is a more proper antonym of allow.
> + pdev->vendor, pdev->device);
> + return false;
> + }
> +
> + pci_warn(pdev, "%04x:%04x is blocklisted - probe will fail.\n",
Perhaps "%04x:%04x exists in vfio-pci device denylist, driver probing
disallowed.\n",...
Thanks,
Alex
> + pdev->vendor, pdev->device);
> +
> + return true;
> +}
> +
> /*
> * Our VGA arbiter participation is limited since we don't know anything
> * about the device itself. However, if the device is the only VGA device
> @@ -1847,6 +1874,9 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> struct iommu_group *group;
> int ret;
>
> + if (vfio_pci_is_blocklisted(pdev))
> + return -EINVAL;
> +
> if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
> return -EINVAL;
>
> @@ -2336,6 +2366,9 @@ static int __init vfio_pci_init(void)
>
> vfio_pci_fill_ids();
>
> + if (disable_blocklist)
> + pr_warn("device blocklist disabled.\n");
> +
> return 0;
>
> out_driver:
[PATCH v2 2/5] vfio/pci: Add device blocklist
Add blocklist of devices that by default are not probed by vfio-pci.
Devices in this list may be susceptible to untrusted application, even
if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
explicitly disable the blocklist.
The blocklist can be disabled via the module parameter disable_blocklist.
Signed-off-by: Giovanni Cabiddu
---
drivers/vfio/pci/vfio_pci.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 7c0779018b1b..ea5904ca6cbf 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -60,6 +60,10 @@ module_param(enable_sriov, bool, 0644);
MODULE_PARM_DESC(enable_sriov, "Enable support for SR-IOV configuration.
Enabling SR-IOV on a PF typically requires support of the userspace PF driver,
enabling VFs without such support may result in non-functional VFs or PF.");
#endif
+static bool disable_blocklist;
+module_param(disable_blocklist, bool, 0444);
+MODULE_PARM_DESC(disable_blocklist, "Disable device blocklist. If set, i.e.
blocklist disabled, then blocklisted devices are allowed to be probed by
vfio-pci.");
+
static inline bool vfio_vga_disabled(void)
{
#ifdef CONFIG_VFIO_PCI_VGA
@@ -69,6 +73,29 @@ static inline bool vfio_vga_disabled(void)
#endif
}
+static bool vfio_pci_dev_in_blocklist(struct pci_dev *pdev)
+{
+ return false;
+}
+
+static bool vfio_pci_is_blocklisted(struct pci_dev *pdev)
+{
+ if (!vfio_pci_dev_in_blocklist(pdev))
+ return false;
+
+ if (disable_blocklist) {
+ pci_warn(pdev,
+"device blocklist disabled - allowing device
%04x:%04x.\n",
+pdev->vendor, pdev->device);
+ return false;
+ }
+
+ pci_warn(pdev, "%04x:%04x is blocklisted - probe will fail.\n",
+pdev->vendor, pdev->device);
+
+ return true;
+}
+
/*
* Our VGA arbiter participation is limited since we don't know anything
* about the device itself. However, if the device is the only VGA device
@@ -1847,6 +1874,9 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
struct iommu_group *group;
int ret;
+ if (vfio_pci_is_blocklisted(pdev))
+ return -EINVAL;
+
if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
return -EINVAL;
@@ -2336,6 +2366,9 @@ static int __init vfio_pci_init(void)
vfio_pci_fill_ids();
+ if (disable_blocklist)
+ pr_warn("device blocklist disabled.\n");
+
return 0;
out_driver:
--
2.26.2
