On Tue, 2 Jan 2024, Alex Williamson wrote:
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?
The level of confidentiality has been left open in the vf-token
implementation across kernel and qemu. Perhaps we need to find a way to
allow a higher level solution to restrict/tighten it further based on
a policy. I don't immediately have a suggestion on how.
Until then the problem is that we are unable to launch the VMs when the PF
is in the uesrspace. For now this patch is only bridging the gap to qemu
commandline.
-vk
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
