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
