> -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Wednesday, December 23, 2015 6:28 PM > To: Ilya Lesokhin <ilyal@xxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; linux- > pci@xxxxxxxxxxxxxxx > Cc: bhelgaas@xxxxxxxxxx; Noa Osherovich <noaos@xxxxxxxxxxxx>; Haggai > Eran <haggaie@xxxxxxxxxxxx>; Or Gerlitz <ogerlitz@xxxxxxxxxxxx>; Liran > Liss <liranl@xxxxxxxxxxxx> > Subject: Re: [RFC 0/2] VFIO SRIOV support > > 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. That’s essentially the same as solution b in original mail which I was hoping to avoid. > > 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, I don't understand the security issue, don't you need root permission for device assignment? > Alex ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
