Re: [RFC 0/2] VFIO SRIOV support

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 2015-12-24 at 07:22 +0000, Ilya Lesokhin wrote:
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Wednesday, December 23, 2015 6:28 PM
> > To: Ilya Lesokhin <ilyal@mellanox.com>; kvm@vger.kernel.org; linux-
> > pci@vger.kernel.org
> > Cc: bhelgaas@google.com; Noa Osherovich <noaos@mellanox.com>;
> > Haggai
> > Eran <haggaie@mellanox.com>; Or Gerlitz <ogerlitz@mellanox.com>;
> > Liran
> > Liss <liranl@mellanox.com>
> > 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?

No.  A privileged entity needs to grant a user ownership of a group and
sufficient locked memory limits to make it useful, but then use of the
group does not require root permission.