On Thu, May 06, 2021 at 07:57:43AM -0500, Connor Kuehl wrote: > On 5/6/21 6:35 AM, Kashyap Chamarthy wrote: > >> It looks like QEMU will expose commands needed for attestation via QMP [3]. > >> But question then is, how to expose those at Libvirt level? Should we allow > >> users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in > >> public APIs, or something completely different? > > > > I know you're just thinking out loud here, but IIUC, isn't allowing > > libvirt API users to communicate directly with QEMU in this case > > departing from the libvirt norm? (Perhaps there's scope of sensible > > exceptions ... as the devil is in the specs.) > > > > Allowing a way to do it is one thing — which is nice for testing and > > development — but saying "just directly communicate via QMP passthrough" > > makes the libvirt API user wonder "why is it okay to passthrough QMP > > commands in this case, but generally such an action is marked as > > 'tainted' by libvirt?" > > Would this be acceptable if libvirt could apply a policy to the QMP > socket which only allowed SEV messages through and dropped all others > (just for an example)? If it's possible to leverage the existing QMP API > for the attestation messages, then libvirt won't have to duplicate a > lower-level attestation protocol. Exposing QMP directly to users or higher level tools is not a desirable thing to do. It is not maintained as a long term stable API. QEMU only guarantees it is compatible across 2 QEMU releases, as this is the length of the QEMU deprecation + removal process. This is not something you want to expose to higher level users who will want their tools to be using something that has compatibility on a much longer time frame. Libvirt provides a long term stable API, such that QEMU has the freedom to evolve its low level API on a much faster timeframe than it would otherwise be able to do. As mentioned in my other response, management apps are not likely to want to expose low level hypervisor impl details directly to their users. They typically expose a higher level concept to users that is agnostic to the hypervisor details, to insulate their users from the implementation and specific hypervisor versions. >From a security POV I would also not be happy with untrusted end users having a direct connection to QMP, even if the command set is filtered. It is just one protocol bug away from users having ability to directly exploit the QEMU process. > This would allow libvirt to essentially proxy relevant messages and this > moves all the attestation complexity to the "edges" (i.e., the > client/relying party and the VMM). I think need to thinking about exactly what the end user needs to be able to accomplish in general terms, not in terms of low level qemu commands. From there we can understand what an app like OpenStack/KubeVirt needs to enable its users to do, and thus what libvirt needs to providing to support OpenStack/KubeVirt in doing this. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
