> -----Original Message----- > From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Monday, October 30, 2017 8:39 AM > To: Christoph Hellwig <h...@infradead.org>; Duyck, Alexander H > <alexander.h.du...@intel.com> > Cc: Wang, Liang-min <liang-min.w...@intel.com>; > alex.william...@redhat.com; linux-kernel@vger.kernel.org; Kirsher, Jeffrey T > <jeffrey.t.kirs...@intel.com>; k...@vger.kernel.org; bhelg...@google.com; > linux-...@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.
