Re: [RFC PATCH v1 0/5] Add virDomainGetSevAttestationReport API

On Thu, Apr 14, 2022 at 02:46:38PM -0400, Tyler Fanelli wrote: > On 4/11/22 10:57 AM, Cole Robinson wrote: >> Maybe the extra key signing is a security fix or something. I haven't >> figured it out. > Signing with the PEK also allows a user to verify the root of trust between > the owner and the platform. The guest owner needs to acquire the PDH before they launch their guest, in order to generate the launch blob. The PDH is signed with the PEK, so they will have surely verified the root of trust with the platform before they even generate the launch blob for the VM. The generated launch blob can't be used on any other host, because the other host won't have the same PDH. If the launch measurement is signed with the PEK, the guest owner has the option of postponing their validation of the root of trust until after the VM is launched. Is that something we need to be able to deal with ? I'm not sure why one would want to postpone validation gven that we're already forced to do other stuff else upfront with SEV/SEV-ES. In the absence of a clearly stated requirement from an application I think we can ignore this. SEV-SNP is of course very different with its guest initiated post launch attestation.

>> But as is it's not clear what this buys us over the launch measurement >> we already report with virDomainGetLaunchSecurityInfo >> >> >> If we figure out what the point of this is, IMO we can more easily >> reason about whether it makes sense to add a Sev specific libvirt API, >> and whether we need virTypedParams for both input and output. For >> example if the API really is specific to this one and only KVM ioctl/QMP >> command, we could hardcode the parameters and skip the virTypedParams >> question entirely. > Interesting, although wouldn't hardcoding an nonce basically render it > useless? User-specified nonce would allow a user to verify that their call > was propagated to firmware at that instance. If they can't supply the nonce, > they can't verify it's an attestation report from that specific call. The launch blob contains a unique TIK/TEK pair, so if the launch measurement validates, the guest owner knows it is associated with a running VM that was created with their designated launch blob. A nonce is usually needed to avoid replay attacks, but I'm not seeing what attack vector is actually present in the SEV/SEV-ES scenario, since AFAIK, the attestation report content never changes once the VM is running. Overall I'm not seeing the need for this API with SEV/SEV-ES at least, and with SEV-SNP IIUC the attestation report is not available to the host, only to the guest ?

With regards, Daniel