On Mon, 6 Nov 2017 15:47:41 -0800 Alexander Duyck <alexander.duyck@xxxxxxxxx> wrote: > On Mon, Nov 6, 2017 at 3:27 PM, Alex Williamson > <alex.williamson@xxxxxxxxxx> wrote: > > On Tue, 31 Oct 2017 12:55:20 +0000 > > "Wang, Liang-min" <liang-min.wang@xxxxxxxxx> wrote: > > > >> > -----Original Message----- > >> > From: David Woodhouse [mailto:dwmw2@xxxxxxxxxxxxx] > >> > Sent: Monday, October 30, 2017 8:39 AM > >> > To: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Duyck, Alexander H > >> > <alexander.h.duyck@xxxxxxxxx> > >> > Cc: Wang, Liang-min <liang-min.wang@xxxxxxxxx>; > >> > alex.williamson@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Kirsher, Jeffrey T > >> > <jeffrey.t.kirsher@xxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; > >> > linux-pci@xxxxxxxxxxxxxxx > >> > 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
