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

On Fri, Feb 25, 2022 at 04:11:27PM -0500, Tobin Feldman-Fitzthum wrote: Agreed, it is out of scope from libvirt's POV. I just wanted to illustrate a possible end-to-end solution for all parties. Since this particular endpoint is an interface exclusively between the guest owner and the AS, it could be said to be an API that does not need standardization. Different implementations may choose to approach it different ways based on how they evaluate the tradeoffs. Agree with what you say here. The distinction of registering a single VM vs registering an image that can be instantiated to many VMs can likely be a decision for the specific implementation of the AS. The reason I suggested registering an individual VM was that I was trying to more closely match the behaviour the virt platform would have if it was not talkin directly with an attestation service. In the manul case a guest owner feeds in the launch blob for each VM at boot time. Thus the compute host can't boot instances of the VM without explicit action from the user. If the AS releases the launch blob and secrets upon request from teh compute host, it can potentially boot many instances of a VM even if the guest owner only asked for one. Of course the host admin can't get into the VMs todo anything, but the mere act of being able to launch many instances without guest owner action might lead to a denial of service attack on other things that the VM talks to. None the less this risk is easy to mitigate, even if you're just registering an image with the AS. It could easily be set to require a confirmation befere releasing more than 'n' instances of the launch blob and secrets represents. It could represent a single VM instances, or it could represent a VM image supporting many instances. Libvirt wouldn't care, the UUID is just a token passed to the AS to indicate what libvirt needs to launch. I'm mostly ambivalent on that question - either way works well enough, though if libvirt needs todo the signing, then libvirt needs to be able to talk to AMD's REST service to acquire the signature. If libvirt doesn't have network access from the compute host, it might not be possible for it to acquire the signature. In terms of the protocol spec, both approaches could be supported. The 'cpu-id' can be provided unconditionally. The 'cert-chain' can be declared to be signed or unsigned. If libvirt is capable of getting a signature, it could provide the cert-chain with thue CEK signed. If not, then the AS could acquire the signature itself as a fallback. My thought was that since the guest owner needs to explicitly give the AS the policy in order to create the correct launch blob, it is pointless for the guest owner to give it to libvirt again in the XML. Just give it the AS and let it pass it onto libvirt automatically. Again though, both approaches work - even if libvirt alrady has the policy, there's no harm in the AS providing the policy in its response again. Essentially I intended it to be the data that is expected by the 'sev-inject-launch-secret' QMP command from QEMU, which is consumed by libvirt. If using the OVMF firmware with the guest then its the OVMF secret table, with other firmware it is whatever they declare it to be. Calling it 'secret-payload' probably makes more sense. 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 :|