On Tue, 2 Jan 2024 18:55:10 +0530
Vivek Kashyap <vivek.kashyap@xxxxxxxxxxxxxxx> wrote:
> The VFIO PCI ABI has been extended to require userspace PF driver to set
> a VF token to a known value. The VF drivers are then required to provide
> this token to access the VF device. The vf-token is set by the PF driver
> before VF drivers can access the device. The kernel provides no means to
> retrieve the token in use; but there is no specification describing the
> distribution or level of confidentiality of the token.
At the same time, both the kernel and this series indicate the token is
a shared secret, which is the reason the kernel provides no means to
access the token. Is it reasonable to have a secret shared token in
xml, logs, and QEMU command line? The token is shared between all VFs
associated to a PF, so as this support more formally moves from a QEMU
one-off hack to libvirt support, are we revealing a secret by promoting
this model?
Furthermore, libvirt has always been able to consider the vfio-pci
device trusted, at least so far as it's provided by a kernel driver.
With VF token support, the VF driver itself may still be a kernel
driver, but the PF is managed via a userspace driver with unknown
capabilities relative to the integrity of the VF device. I don't know
if we need to or how we take into account that lack of device
authentication. Certainly without some degree of attestation of the PF
driver and VF token, or potentially a mechanism for a more
cryptographic statement of trust, such a device ought not to be
involved with a confidential VM.
I'm not sure what needs to be done here, maybe the device level trust
is a problem for a higher level management tool, but I'd like to take a
more thoughtful look at the implications of VF token support as we move
up the stack rather than position this as simply filling a gap in QEMU
vfio-pci support. Thanks,
Alex
> Qemu has been
> extended to require the vf-token when vf device is used. An important
> point to note is that the vf-token is required only when both the PF and
> VF are used in userspace.
>
> This patch series adds support to provide the vf-token (uuid format) in the
> domain XML and to generate the qemu commandline including the vf-token.
>
> To support vf-token the new element will be used as follows:
> <hostdev mode='subsystem' type='pci' managed='yes'>
> <driver name='vfio'/>
> <source>
> <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'>
> <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/>
> </address>
> </source>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
> </hostdev>
>
> The generated commandline will include the following:
>
> -device {"driver":"vfio-pci","host":"0000:00:0.1",
> "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
> "id":"hostdev0","bus":"pci.0","addr":"0x1"}
>
> Changes since initial RFC based on review comments received:
> 1. Added documentation
> 2. Added test cases and ran successful test suite after each patch commit
> 3. fixed spaces, coding sytle, and uuid string format
> 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional
>
> Vivek Kashyap (8):
> Define the vf-token extension for PCI device
> Introduce the vf-token qemu capability
> This patch introduces the PCI address extension flag for vf-token
> This patch introduces new XML parser/formatter functions for parsing
> the vf-token
> Introduce a validation function for vf-token support in qemu and
> generate vf-token device attribute in qemu command line
> Provide information about the vf-token flag
> Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
> test suites
> Update news about vf-token
>
> NEWS.rst | 8 +++
> docs/formatdomain.rst | 3 ++
> src/conf/device_conf.c | 49 ++++++++++++++++---
> src/conf/domain_addr.h | 1 +
> src/conf/domain_conf.c | 8 +++
> src/conf/schemas/basictypes.rng | 7 +++
> src/libvirt_private.syms | 1 +
> src/qemu/qemu_capabilities.c | 3 ++
> src/qemu/qemu_capabilities.h | 1 +
> src/qemu/qemu_command.c | 8 +++
> src/qemu/qemu_domain_address.c | 3 ++
> src/qemu/qemu_validate.c | 20 ++++++++
> src/util/virpci.c | 7 +++
> src/util/virpci.h | 10 ++++
> .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 +
> .../caps_8.1.0_x86_64.xml | 1 +
> .../caps_8.2.0_x86_64.xml | 1 +
> .../hostdev-vfio-vf-token.x86_64-latest.args | 34 +++++++++++++
> .../hostdev-vfio-vf-token.xml | 22 +++++++++
> tests/qemuxml2argvtest.c | 1 +
> .../hostdev-vfio-vf-token.x86_64-latest.xml | 40 +++++++++++++++
> tests/qemuxml2xmltest.c | 1 +
> 22 files changed, 223 insertions(+), 7 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
> create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
> create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml
>
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
