Re: [ PATCH vf-token 0/8] Introduce vf-token when using userspace PF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 08, 2024 at 12:44:01 +0100, Peter Krempa wrote:
> 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.

Forgot to add:

If you need a way to test it with a libvirt-started VM in the interim
until the qemu commandline configuration accepts secrets (which should
be fairly trivial, and we will accept patches based on qemu code
which was pushed but not released yet) you can use device-property
overrides:

https://libvirt.org/drvqemu.html#overriding-properties-of-qemu-devices

note that it has the same implications about supportability as using
commandline overrides:

https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux