On Wed, Jan 03, 2024 at 22:42:41 +0530, Vivek Kashyap wrote: > > > 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. If there is even a slight expectation of confidentiality (IMO just calling it a 'secret' in documentation is enough to justify that expectation) it should be treated as such. Thus qemu needs to add the possibility to pass it via the 'secret' object, so that libvirt can pass it encrypted. On the device commandline we'll just pass the alias to the secret. There's a well documented and maintained way to do that so it should be a very straightforward and quick modification. > 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. The above should be done prior doing this in libvirt so that we can use the new approach without having any duplicate code. _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
