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: > Some comments on the example protocol stuff > > On 2/23/22 1:38 PM, Dov Murik wrote: >> +cc Tobin, James >> >> On 23/02/2022 19:28, Daniel P. Berrangé wrote: >>> >>> >>> What could this look like from POV of an attestation server API, if >>> we assume HTTPS REST service with a simple JSON payload .>> >>> >>> * Guest Owner: Register a new VM to be booted: > We're trying to set the API between libvirt and the AS. I would assume > that the API between the AS and the guest owner is out of scope, > although maybe this is just an example. Agreed, it is out of scope from libvirt's POV. I just wanted to illustrate a possible end-to-end solution for all parties. >>> >>> POST /vm/<UUID> > Note that this is a privileged endpoint (unlike the ones below). >>> >>> Request body: >>> >>> { >>> "scheme": "amd-sev", >>> "cloud-cert": "certificate of the cloud owner that signs the PEK", >>> "policy": 0x3, >>> "cpu-count": 3, >>> "firmware-hashes": [ >>> "xxxx", >>> "yyyy", >>> ], > I think we'd need to provide the full firmware binary rather than just > the hash if we plan to calculate the launch digest in the AS. > Alternatively the guest owner can calculate the launch digest themself > and pass it to the AS. This is what kbs-rs does. There are pros and cons > to both and we should probably support both (which should be easy). 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. >>> "kernel-hash": "aaaa", >>> "initrd-hash": "bbbb", >>> "cmdline-hash": "cccc", >>> "secrets": [ >>> { >>> "type": "luks-passphrase", >>> "passphrase": "<blah>" >>> } >>> ] >>> } >>> > > Registering an individual VM is kind of an interesting perspective. With > kbs-rs, rather than registering an individual VM, the guest owner > registers secrets and can set a policy (which specifies launch > parameters like the SEV policy) for each secret. Then secrets are > released to VMs that meet the policy requirements. There isn't really > any tracking of an individual VM (besides the secure channel briefly > used for secret injection). In SEV(-ES) individual VMs don't really have > an identity separate from their launch parameters and launch > measurement. I guess we're not trying to design an AS here, so we can > leave for another time. 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

>>> >>> >>> * Libvirt: Request permission to launch a VM on a host >>> >>> POST /vm/<UUID>/launch > Since I've been thinking about VM identity a little differently, our > setup for the UUID is a bit different as well. We use a UUID to track a > connection (as in TIK, TEK), but this is not known at the time of the > launch request (aka GetBundle request). Instead, the UUID is returned in > the launch response so that it can be used for the secret request. > > If we have a UUID in the launch request, it creates an interesting > coordination requirement between the CSP and the AS. Imagine a situation > where we spin up a bunch of identical VMs dynamically. Here the guest > owner would have to register a new VM with a UUID for each instance and > then get all of that information over to libvirt. This seems difficult. > Shifting focus from VMs to secrets and policies and automatically > provisioning the UUID sidesteps this issue. This is especially important > for something like Confidential Containers (of course CC doesn't use > libvirt but we'd like to share the AS API). From the libvirt POV, we don't have to declare what the UUID 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.

>>> >>> Request body: >>> >>> { >>> "pdh": "<blah>", >>> "cert-chain": "<blah>", >>> "cpu-id": "<CPU ID>", > There's an interesting question as to whether the CEK should be signed > by libvirt or by the AS. 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. >>> ...other relevant bits... >>> } >>> >>> Service decides if the proposed host is acceptable >>> >>> Response body (on success) >>> >>> { >>> "session": "<blah>", >>> "owner-cert": "<blah>", >>> "policy": 3, > I've assumed that the policy would be part of the request, having been > set in the libvirt XML. 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.

>>> * Libvirt: Request secrets to inject to launched VM >>> >>> POST /vm/<UUID>/validate >>> >>> Request body: >>> >>> { >>> "api-minor": 1, >>> "api-major": 2, >>> "build-id": 241, >>> "policy": 3, >>> "measurement": "<blah>", >>> "firmware-hash": "xxxx", >>> "cpu-count": 3, >>> ....other relevant stuff.... >>> } >>> >>> Service validates the measurement... >>> >>> Response body (on success): >>> >>> { >>> "secret-header": "<blah>", >>> "secret-table": "<blah>", > Referring to secret payload format as OVMF secret table? 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