On Mon, 8 Jan 2024, Alex Williamson wrote:
On Mon, 8 Jan 2024 23:32:04 +0530 (IST)
Vivek Kashyap <vivek.kashyap@xxxxxxxxxxxxxxx> wrote:
On Mon, 8 Jan 2024, Alex Williamson wrote:
On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
Vivek Kashyap <vivek.kashyap@xxxxxxxxxxxxxxx> 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@xxxxxxxxx
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,
Thanks for the explanation.
I'll follow-up on the secret object implementation.
-vk
Alex
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
