On Mon, 25 Jul 2016 15:34:34 +0000 Ilya Lesokhin <ilyal@xxxxxxxxxxxx> wrote: > Hi Alex, > It seems that I'm missing something because I fail to see how the sysfs interface solves > any of the problems you've pointed out in the current code. If the kernel allows a user who owns a PF to spawn VFs then it becomes the kernel's problem how to define and enforce the policy around those devices (ie. who is allowed to use them, how does ownership get transferred, what do we consider secure vs insecure, etc). On the other hand if we do not allow a user that direct path and they need to interact through a trusted channel to create those VFs, then it becomes the problem of the entity creating them how to address those policy questions. That's a big difference. In general I think it's a bad idea to implement policy in the kernel, the kernel should provide the tools to allow userspace to manage the policy. > Can you please clarify what you want us to do on the kernel side besides moving to the sysfs interface? > How do we prevent the administrator from unbinding the VFs from vfio and binding them to the default driver? > How does the new model prevent the administrator from assigning the VFs to other VM? In both cases the answer is "we don't". Those are questions that would need to be addressed if the kernel was implementing the policy. The kernel already has an interface for creating SRIOV VFs and it's up to userspace how to manage that in a secure way. If someone has a use case where a user owned PF spawns a host kernel owned VF, that's for userspace to determine whether it's valid. sriov_driver_override is only a suggestion towards facilitating user managed VFs, allowing the creator of the VFs to more concisely control the driver binding for those VFs. Thanks, Alex > -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Monday, July 25, 2016 6:08 PM > To: Haggai Eran <haggaie@xxxxxxxxxxxx> > Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; Ilya Lesokhin <ilyal@xxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; Noa Osherovich <noaos@xxxxxxxxxxxx>; Or Gerlitz <ogerlitz@xxxxxxxxxxxx>; Liran Liss <liranl@xxxxxxxxxxxx> > Subject: Re: [PATCH v2 0/2] VFIO SRIOV support > > On Mon, 25 Jul 2016 10:53:56 +0300 > Haggai Eran <haggaie@xxxxxxxxxxxx> wrote: > > > On 7/19/2016 10:43 PM, Alex Williamson wrote: > > > Thinking about this further, it seems that trying to create this IOV > > > enablement interface through a channel which is explicitly designed > > > to interact with an untrusted and potentially malicious user is the > > > wrong approach. We already have an interface for a trusted entity > > > to enable VFs, it's through pci-sysfs. Therefore if we were to use > > > something like libvirt to orchestrate the lifecycle of the VFs, I > > > think we remove a lot of the problems. In this case QEMU would > > > virtualize the SR-IOV capability (maybe this is along the lines of > > > what Kevin was thinking), but that virtualization would take a path > > > out through the QEMU QMP interface to execute the SR-IOV change on > > > the device rather than going through the vfio kernel interface. A > > > management tool like libvirt would then need to translate that into > > > sysfs operations to create the VFs and do whatever we're going to do > > > with them (device_add them back to the VM, make them available to a > > > peer VM, make them available to the host *gasp*). VFIO in the > > > kernel would need to add SR-IOV support, but the only automatic > > > SR-IOV path would be to disable IOV when the PF is released, > > > enabling would only occur through sysfs. We would probably need a > > > new pci-sysfs interface to manage the driver for newly created VFs > > > though to avoid default host drivers (sriov_driver_override?). In > > > this model QEMU is essentially just making requests to other > > > userspace entities to perform actions and how those actions are > > > performed can be left to userspace policy, not kernel policy. I > > > think this would still satisfy the development use case, the > > > enabling path just takes a different route where privileged > > > userspace is more intimately involved in the process. Thoughts? > > > Thanks, > > > > I understand the desire to use a different interface such as sysfs for > > the trusted user-space component. I'm not sure though how using > > sriov_driver_override solves the issues we have been discussing. After > > SR-IOV is enabled by libvirt, it is still possible for the > > administrator (or another trusted daemon racing with libvirt) to open > > the VFs with VFIO before libvirt had a chance to open them and send them to QEMU. > > > > Are you okay with that? > > If a privileged entity like libvirt is creating VFs on behalf of a user, it's going to be that entity's responsibility to claim ownership of all those created VFs. sriov_driver_override is just one suggestion that might help facilitate that. Others might be necessary, but ultimately it's not the kernel's problem to work out which entity gets to take ownership of those devices, that's a userspace problem, just as it is already today. Thanks, > > Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
