On Tue, 14 Jul 2020 07:36:07 +0100
Giovanni Cabiddu <giovanni.cabi...@intel.com> 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 <giovanni.cabi...@intel.com>
> ---
> 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:
