Re: [PATCH] Enable SR-IOV instantiation through /sys file

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

On Mon, 6 Nov 2017 15:47:41 -0800
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On Mon, Nov 6, 2017 at 3:27 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > On Tue, 31 Oct 2017 12:55:20 +0000
> > "Wang, Liang-min" <liang-min.wang@intel.com> wrote:
> >  
> >> > -----Original Message-----
> >> > From: David Woodhouse [mailto:dwmw2@infradead.org]
> >> > Sent: Monday, October 30, 2017 8:39 AM
> >> > To: Christoph Hellwig <hch@infradead.org>; Duyck, Alexander H
> >> > <alexander.h.duyck@intel.com>
> >> > Cc: Wang, Liang-min <liang-min.wang@intel.com>;
> >> > alex.williamson@redhat.com; linux-kernel@vger.kernel.org; Kirsher, Jeffrey T
> >> > <jeffrey.t.kirsher@intel.com>; kvm@vger.kernel.org; bhelgaas@google.com;
> >> > linux-pci@vger.kernel.org
> >> > Subject: Re: [PATCH] Enable SR-IOV instantiation through /sys file
> >> >
> >> > On Sat, 2017-10-28 at 23:16 -0700, Christoph Hellwig 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.  
> >> >
> >> > I have them, which is why I'm patching the UIO driver to allow num_vfs
> >> > to be set. I don't even want to *use* the UIO driver for any purpose
> >> > except to make that appear in sysfs. It's all handled in the device.
> >> >
> >> > (I think we might be able to just give the PF out to a guest as if it
> >> > were just another VF, but I don't think we actually *do* that right
> >> > now).  
> >>
> >> Under UEFI secure boot environment, kernel puts restrictions on UIO and its derivatives.
> >> So, user-space function/driver based upon UIO is no longer working under UEFI secure
> >> boot environment. The next viable option is vfio-pci, hence this patch in parallel with
> >> UIO work.  
> >
> > If you want a PF driver that does nothing other than allow SR-IOV to be
> > enabled, doesn't that scream pci-stub?  Trying to overlay it onto a
> > driver that also allows userspace driver access to that device seems
> > like the worst idea.  Thanks,
> >
> > Alex  
> 
> So for the case where a user-space agent is running the actual PF how
> is it you suggest we go about quarantining the interfaces? What kind
> of behavior is it you are expecting to see? Should we look into a way
> to clear match_driver for the VF interfaces so the drivers won't load
> on them at all, or are you expecting something like vfio-pci to be
> selected to auto-load on them since the PF is already running that?

Disabling driver auto probing would be a good start.  I expect we don't
want to disallow the admin from binding VFs to host drivers, but
perhaps we should taint the host if they do.  I don't think anyone
wants to sign-up to support a device in the host that is potentially
compromised by an unknown, possibly proprietary, userspace PF driver.
Some work needs to be done on managing the VF enablement life cycle,
for instance can VFs be enabled while the user is already using the
PF?  We need some sort of signaling and handshake if the user driver
allows concurrent changes, blocking otherwise.  Also how does the user
being able to reset the PF affect the situation?  That needs to be
evaluated and handled.  Thanks,

Alex