On Wed, 2015-12-23 at 07:43 +0000, Ilya Lesokhin wrote: > Hi Alex, > Regarding driver_override, as far as I know you can only use it on > devices that were already discovered. Since the devices do not exist > before the call to pci_enable_sriov(...) > and are already probed after the call it wouldn't really help us. I > would have to unbind them from their default driver and bind them to > VFIO like solution a in my original mail.
If you allow them to be bound to their default driver, then you've already created the scenario of a user own PF creating host own VFs, which I think is unacceptable. The driver_override can be set before drivers are probed, the fact that pci_enable_sriov() doesn't enable a hook for that is something that could be fixed. > You are right about the ownership problem and we would like to > receive input regarding what is the correct way of solving this. > But in the meantime I think our solution is quite useful even though > if it requires root privileges. We hacked libvirt so that it would > run qemu as root and without device cgroup. > > In any case, don't you think that assigning those devices to VFIO > should be safe? Does the VFIO driver makes any unsafe assumptions on > the VF's that might allow a guest to crash the hypervisor? > > I am somewhat concerned that the VM could trigger some backdoor > reset while the hypervisor is running pci_enable_sriov(...). But I'm > not really sure how to solve it. > I guess you have to either stop the guest entirely to enable sriov or > make it privileged. > > Regarding having the PF controlled by one user while the other VFs > are controlled by other user, I actually think it might be an > interesting use case. It may be, but it needs to be an opt-in, not a security accident. The interface between a PF and a VF is essential device specific and we don't know exactly how isolated each VF is from the PF. In the typical scenario of the PF being owned by the host, we have a certain degree of trust in the host, it's running the VM after all, if it wanted to compromise it, it could. We have no implicit reason to trust a PF running in a guest though. Can the snoop VF traffic, can they generate DMA outside of the container of the PF using the VF? We can't be sure. So unless you can make the default scenario be that VFs created by a user own PF are only available for use by that user, without relying on userspace to intervene, it seems like any potential usefulness is trumped by a giant security issue. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
