[0/5] vfio/pci: add blocklist and disable qat

Message

Cabiddu, Giovanni July 1, 2020, 11:02 a.m. UTC

This patchset defines a blocklist of devices in the vfio-pci module and adds
the current generation of Intel(R) QuickAssist devices to it as they are
not designed to run in an untrusted environment.

By default, if a device is in the blocklist, the probe of vfio-pci fails.
If a user wants to use a device in the blocklist, he needs to disable the
full blocklist providing the option disable_blocklist=1 at the load of
vfio-pci or specifying that parameter in a config file in /etc/modprobe.d.

This series also moves the device ids definitions present in the qat driver
to linux/pci_ids.h since they will be shared between the vfio-pci and the qat
drivers and replaces the custom ADF_SYSTEM_DEVICE macro with PCI_VDEVICE.

The series is applicable to Herbert's tree but only partially applicable to
Alex's tree due to a merge conflict.

Giovanni Cabiddu (5):
  PCI: add Intel QuickAssist device IDs
  vfio/pci: add device blocklist
  vfio/pci: add qat devices to blocklist
  crypto: qat - replace device ids defines
  crypto: qat - use PCI_VDEVICE

 drivers/crypto/qat/qat_c3xxx/adf_drv.c        | 11 ++---
 drivers/crypto/qat/qat_c3xxxvf/adf_drv.c      | 11 ++---
 drivers/crypto/qat/qat_c62x/adf_drv.c         | 11 ++---
 drivers/crypto/qat/qat_c62xvf/adf_drv.c       | 11 ++---
 .../crypto/qat/qat_common/adf_accel_devices.h |  6 ---
 drivers/crypto/qat/qat_common/qat_hal.c       |  7 +--
 drivers/crypto/qat/qat_common/qat_uclo.c      |  9 ++--
 drivers/crypto/qat/qat_dh895xcc/adf_drv.c     | 11 ++---
 drivers/crypto/qat/qat_dh895xccvf/adf_drv.c   | 11 ++---
 drivers/vfio/pci/vfio_pci.c                   | 48 +++++++++++++++++++
 include/linux/pci_ids.h                       |  6 +++
 11 files changed, 87 insertions(+), 55 deletions(-)

Comments

Christoph Hellwig July 1, 2020, 12:42 p.m. UTC | #1

On Wed, Jul 01, 2020 at 12:02:57PM +0100, Giovanni Cabiddu wrote:
> This patchset defines a blocklist of devices in the vfio-pci module and adds
> the current generation of Intel(R) QuickAssist devices to it as they are
> not designed to run in an untrusted environment.

How can they not be safe?  If any device is not safe to assign the
whole vfio concept has major issues that we need to fix for real instead
of coming up with quirk lists for specific IDs.

Christoph Hellwig July 10, 2020, 3:48 p.m. UTC | #2

On Wed, Jul 01, 2020 at 01:42:09PM +0100, Christoph Hellwig wrote:
> On Wed, Jul 01, 2020 at 12:02:57PM +0100, Giovanni Cabiddu wrote:
> > This patchset defines a blocklist of devices in the vfio-pci module and adds
> > the current generation of Intel(R) QuickAssist devices to it as they are
> > not designed to run in an untrusted environment.
> 
> How can they not be safe?  If any device is not safe to assign the
> whole vfio concept has major issues that we need to fix for real instead
> of coming up with quirk lists for specific IDs.

No answer yet:  how is this device able to bypass the IOMMU?  Don't
we have a fundamental model flaw if a random device can bypass the
IOMMU protection?  Except for an ATS bug I can't really think of a way
how a device could bypass the IOMMU, and in that case we should just
disable ATS.

Cabiddu, Giovanni July 10, 2020, 4:13 p.m. UTC | #3

On Fri, Jul 10, 2020 at 04:48:07PM +0100, Christoph Hellwig wrote:
> On Wed, Jul 01, 2020 at 01:42:09PM +0100, Christoph Hellwig wrote:
> > On Wed, Jul 01, 2020 at 12:02:57PM +0100, Giovanni Cabiddu wrote:
> > > This patchset defines a blocklist of devices in the vfio-pci module and adds
> > > the current generation of Intel(R) QuickAssist devices to it as they are
> > > not designed to run in an untrusted environment.
> > 
> > How can they not be safe?  If any device is not safe to assign the
> > whole vfio concept has major issues that we need to fix for real instead
> > of coming up with quirk lists for specific IDs.
> 
> No answer yet:  how is this device able to bypass the IOMMU?  Don't
> we have a fundamental model flaw if a random device can bypass the
> IOMMU protection?  Except for an ATS bug I can't really think of a way
> how a device could bypass the IOMMU, and in that case we should just
> disable ATS.
Apologies.
This is specific to the QAT device and described in QATE-39220 in the
QAT release notes:
https://01.org/sites/default/files/downloads/336211-014-qatforlinux-releasenotes-hwv1.7_0.pdf
If a request with an address outside of the IOMMU domain attached to the
device is submitted, the device can lock up or induce a platform hang.

Regards,