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.
Yes, that sounds good. We need to add the mechanism to pass the vf-token via
a secret object. However, until it is done we are unable to proceed with our
VMs with PF in the userspace unless we provide the vf-token as in this series.
So for now either
a) the qemu commit needs to be revert (so that we can continue without
providing vf-token uuid), OR
b) We add libvirt support for clear-text vf-token, then add the choice to
qemu to additionally provide the vf-token via a secret object and then
update libvirt to pass the encrypted secret.
-vk
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
