linux-kernel - [PATCH v2] vfio/pci: Quiet broken INTx whining when INTx is unsupported by device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 21 Mar 2018 16:39:36 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, aik@...abs.ru,
        alex.williamson@...hat.com, leedom@...lsio.com,
        ganeshgr@...lsio.com, arjun@...lsio.com, indranil@...lsio.com,
        nirranjan@...lsio.com
Subject: [PATCH v2] vfio/pci: Quiet broken INTx whining when INTx is
 unsupported by device

The intent of commit 2170dd04316e ("vfio-pci: Mask INTx if a device is
not capabable of enabling it") was to disallow the user from seeing
that the device supports INTx if the platform is incapable of enabling
it.  The detection of this case however incorrectly includes devices
which natively do not support INTx, such as SR-IOV VFs.  We don't need
the nointx handling code for such devices, nor do we want to issue a
broken INTx masking warning.  Check whether the device supports INTx
before enabling nointx and remove the free pass for non-i40e Intel
devices.

Reported-by: Arjun Vynipadath <arjun@...lsio.com>
Fixes: 2170dd04316e ("vfio-pci: Mask INTx if a device is not capabable of enabling it")
Acked-by: Casey Leedom <leedom@...lsio.com>
Signed-off-by: Alex Williamson <alex.williamson@...hat.com>
---

v2:

One more quick spin on this, barring issues I'd like to get a pull
request in for rc7.  The regression was originally masked because I
generally test on Intel SR-IOV, which doesn't exhibit the problem
because it traps in the switch case above, as vendor quirks were the
original intent of this funciton.  v2 drops that default case so that
all vendors reach the pdev->irq test, which I think was also the
original intent of 2170dd04316e.  Leaving Casey's ack since it
shouldn't affect testing on non-Intel parts.

 drivers/vfio/pci/vfio_pci.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index b0f759476900..dccc2feca6ec 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -192,6 +192,8 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev);
  */
 static bool vfio_pci_nointx(struct pci_dev *pdev)
 {
+	u8 pin;
+
 	switch (pdev->vendor) {
 	case PCI_VENDOR_ID_INTEL:
 		switch (pdev->device) {
@@ -202,12 +204,21 @@ static bool vfio_pci_nointx(struct pci_dev *pdev)
 		case 0x1583 ... 0x158b:
 		case 0x37d0 ... 0x37d2:
 			return true;
-		default:
-			return false;
 		}
 	}

-	if (!pdev->irq)
+	pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
+
+	/*
+	 * If the device supports INTx, but it cannot be enabled, invoke
+	 * nointx to mask the pin value and INTx IRQ_INFO to the user.
+	 *
+	 * NB. Generally nointx depends on at least being able to prevent the
+	 * device from generating INTx, so ideally we might check if INTx
+	 * masking is supported, but perhaps we can interpret lack of an irq
+	 * as lack of routing and presume the INTx line is unwired.
+	 */
+	if (pin && !pdev->irq)
 		return true;

 	return false;