> -----Original Message----- > From: David Woodhouse [mailto:[email protected]] > Sent: Monday, October 30, 2017 8:39 AM > To: Christoph Hellwig <[email protected]>; Duyck, Alexander H > <[email protected]> > Cc: Wang, Liang-min <[email protected]>; > [email protected]; [email protected]; Kirsher, Jeffrey T > <[email protected]>; [email protected]; [email protected]; > [email protected] > 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.
