[RFC] Allowing SEV attestation

[Daniel P. Berrangé]

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 :|