REST service for libvirt to simplify SEV(ES) launch measurement

[Tobin Feldman-Fitzthum]

On 2/23/22 1:38 PM, Dov Murik wrote:
> +cc Tobin, James
> 
> On 23/02/2022 19:28, Daniel P. Berrangé wrote:
>> Extending management apps using libvirt to support measured launch of
>> QEMU guests with SEV/SEV-ES is unreasonably complicated today, both for
>> the guest owner and for the cloud management apps. We have APIs for
>> exposing info about the SEV host, the SEV guest, guest measurements
>> and secret injections. This is a "bags of bits" solution. We expect
>> apps to them turn this into a user facting solution. It is possible
>> but we're heading to a place where every cloud mgmt app essentially
>> needs to reinvent the same wheel and the guest owner will need to
>> learn custom APIs for dealing with SEV/SEV-ES for each cloud mgmt
>> app. This is pretty awful.  We need to do a better job at providing
>> a solution that is more general purpose IMHO.
>>

A few general thoughts,

We've been working on our own attestation server over the last few
weeks. We're in the process of making it available publicly
<https://github.com/confidential-containers/kbs-rs/pull/1>

In working on this, we've come up against many of the things that you
are talking about here.

Note in particular that we provide a client script called LaunchVM.py
that uses libvirt to start an SEV VM in conjunction with the attestation
server. This is basically a stand in for a management app or cloud
control plane. The modifications needed to launch an SEV VM are not
particularly extensive. I agree with some of your comments though. In
some ways it might be nice to have libvirt take care of things and hide
the complexity from the management app.

When we started working on our attestation server, our initial plan was
to make PRs to libvirt that would add one end of the attestation API to
libvirt, which would directly query the KBS. This is basically what you
are proposing. We decided against this for a couple of reasons.

First, we were concerned that libvirt might not have network
connectivity to an arbitrary attestation server in a cloud environment.
We had envisioned that the guest owner would provide a URI for their
attestation server as part of the XML. This assumes that the node where
the VM is going to run can connect to an attestation server living
somewhere on the internet. I think that this might be challenging in
some cloud environments. By having the management app connect to libvirt
and the attestation server, we add some flexibility.

Second, we were worried that it would be difficult to settle on and
maintain a standard. Fortunately this discussion is only relevant for
SEV(-ES), given that SNP measurements are reported from inside the
guest, but nonetheless there are already a number of approaches for
handling things. By using a management app, each CSP can easily adapt
the standard libvirt api into whatever attestation API they want. This
does put a burden on the management apps, but it might sidestep a tricky
problem for libvirt and like I said, we found it pretty easy to write
our LaunchVM script (except for the CEK issue mentioned elsewhere).

Finally, we didn't think that there would be any interest in the libvirt
community. It seems like we might have been wrong about this. Like I
said, our first instinct was to extend libvirt, and if there is interest
in doing this, we could dust off those ideas. I certainly have a lot of
ideas about how to design an API for attestation. Of course we now have
an API for attestation that we think is pretty good. It is gRPC, but we
are thinking about also supporting a REST interface. If an attestation
api is added to libvirt, I will definitely try to be involved, although
honestly I think it's fine, and in some ways maybe better, to have the
management app take care of things.

I may comment separately on some of the details that you have provided.

-Tobin

>>
>> Regards,
>> Daniel