From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [RFC 0/2] VFIO SRIOV support Date: Wed, 23 Dec 2015 09:28:20 -0700 Message-ID: <1450888100.2950.87.camel@redhat.com> References: <1450791734-3907-1-git-send-email-ilyal@mellanox.com> <1450798558.22385.7.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "bhelgaas@google.com" , Noa Osherovich , Haggai Eran , Or Gerlitz , Liran Liss To: Ilya Lesokhin , "kvm@vger.kernel.org" , "linux-pci@vger.kernel.org" Return-path: In-Reply-To: Sender: linux-pci-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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=C2=A0=C2=A0it wouldn't really h= elp 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. =C2=A0The driver_override can be set bef= ore 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.=C2=A0 > 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. >=20 > 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? >=20 > I am somewhat concerned that the VM=C2=A0=C2=A0could trigger some bac= kdoor > 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. >=20 > 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. =C2=A0= 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. =C2=A0In the ty= pical 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. =C2=A0We have no implicit reason to trust a PF running in a guest though. =C2=A0Can the snoop VF traffic, can they gen= erate DMA outside of the container of the PF using the VF? =C2=A0We can't be = sure. =C2=A0So unless you can make the default scenario be that VFs created b= y 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. =C2=A0Thanks, Alex