linux-kernel - RE: [PATCH v2] vfio/pci: Mask buggy SR-IOV VF INTx support

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Sep 2018 22:56:41 +0000
From:   "Eads, Gage" <gage.eads@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Raj, Ashok" <ashok.raj@...el.com>
CC:     "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] vfio/pci: Mask buggy SR-IOV VF INTx support

Hi Alex,

This patch passes testing with the 0x270c device, and (when I comment out its known_bogus_vf_intx_pin entry) the warning is triggered by QEMU.

Thanks,
Gage

> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@...hat.com]
> Sent: Thursday, September 20, 2018 3:03 PM
> To: kvm@...r.kernel.org; Raj, Ashok <ashok.raj@...el.com>; Eads, Gage
> <gage.eads@...el.com>
> Cc: gnomes@...rguk.ukuu.org.uk; linux-kernel@...r.kernel.org
> Subject: [PATCH v2] vfio/pci: Mask buggy SR-IOV VF INTx support
> 
> The SR-IOV spec requires that VFs must report zero for the INTx pin register as
> VFs are precluded from INTx support.  It's much easier for the host kernel to
> understand whether a device is a VF and therefore whether a non-zero pin
> register value is bogus than it is to do the same in userspace.  Override the INTx
> count for such devices and virtualize the pin register to provide a consistent view
> of the device to the user.
> 
> As this is clearly a spec violation, warn about it to support hardware validation,
> but also provide a known whitelist as it doesn't do much good to continue
> complaining if the hardware vendor doesn't plan to fix it.
> 
> Known devices with this issue: 8086:270c
> 
> Signed-off-by: Alex Williamson <alex.williamson@...hat.com>

Tested-by: Gage Eads <gage.eads@...el.com>