On Sat, Oct 28, 2017 at 11:16 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, Oct 27, 2017 at 11:20:41PM +0000, Duyck, Alexander H wrote: >> I don't see this so much as a security problem per-se. It all depends >> on the hardware setup. If I recall correctly, there are devices where >> the PF function doesn't really do much other than act as a bit more >> heavy-weight VF, and the actual logic is handled by a firmware engine >> on the device. > > Can you cite an example? While those surely could exist in theory, > I can't think of a practical example. If I recall the neterion vxge driver fell into that category if I recall correctly. Basically the hardware is preconfigured for some number of VFs and their driver just calls pci_enable_sriov and enables them. One other thing I forgot about is the fact that we already have drivers such as igb, ixgbe, and vxge floating around that will leave SR-IOV enabled if the driver is loaded while VFs are direct assigned to guests. As a side effect we can sort of already support assigning vfio-pci to a driver that has SR-IOV enabled. > Maybe we can start with the practical use case for this patch. That > is what device is this intended for? If I am not mistaken the typical use case for a patch like this is to support loading something like DPDK on a networking device PF, whlie the VFs are assigned to virtualized guests and/or containers. It would move the control of the PF/VFs into use space, but in the grand scheme of things it isn't much different then when a virtualized guest has a VF and has no direct control over the configuration of it since the host is managing that. So if the root user is enabling SR-IOV and allocating VFs on a device that is running the vfio-pci driver the assumption is that the root user must be trusting the application that is running on top of the vfio-pci driver to behave correctly.
