On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote: > > > > 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. As I've stated above, for libvirt we should consider only passing it via the 'secret' object. _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
