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: > On Mon, 8 Jan 2024, Alex Williamson wrote: > >> On Mon, 8 Jan 2024 18:42:19 +0530 (IST) >> Vivek Kashyap <vivek.kashyap(a)linux.intel.com&gt; wrote: >> >>> ... >>>>> As I've stated above, for libvirt we should consider only passing it via >>>>> the 'secret' object. >>> >>> Sounds good. Will follow this up. >>> >>> Alex - will you be working on the qemu update? >> >> I'm not the one driving a use case that requires libvirt support for >> vf-token. Thanks, > > Not asking wrt libvirt but queried wrt qemu due to your original > implementation in qemu: > > https://lore.kernel.org/lkml/20200204161737.34696b91@w520.home > https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d 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,