Re: [PATCH v2 2/5] vfio/pci: Add device blocklist

[Alex Williamson]

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