Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF

On Mon, 8 Jan 2024 23:32:04 +0530 (IST) Vivek Kashyap <vivek.kashyap(a)linux.intel.com&gt; wrote: Per the first link: NB. It's unclear whether there's value to this QEMU support without further exposure of SR-IOV within a VM. This is meant mostly as a test case where the real initial users will likely be DPDK drivers. I didn't author the commit in the second link. Based on the above comment it's clear that QEMU, or any VMM use case, was not the initial target for vf-token support. It was intended for DPDK, which already has a pretty low security model. QEMU was only a proof of concept with a code base more familiar to me. I also noted in the above my expectation that SR-IOV would be the legitimate use case in QEMU. My thought there was that QEMU would set a private vf-token and emulate an SR-IOV capability to the guest. Enabling SR-IOV by the guest would trigger a call-out to libvirt to effect the change via host pci-sysfs and attach the resulting VFs back to the VM. The vf-token would remain private and act as a measure of protection against other use cases for the VFs. I've never been strongly in favor of general vf-token support in QEMU. If a VF requires a vf-token, then by definition the PF is being managed by another vfio userspace driver. Somebody needs to decide whether that userspace driver is trustworthy since it may have access to all the data accessible to the VF. An in-kernel PF driver would be trusted by default, so what's the underlying motivation to make vf-token support more ubiquitous through the stack? In my view, this support attempts to de-emphasize the security risk of a 3rd party userspace PF driver while also promoting their very existence. I won't deny that use cases for this exist, but I have yet to see evidence that those are use cases I care to promote. So no, I won't be implementing a secret object implementation of this in QEMU. Thanks, Alex