On 4/20/22 5:45 AM, Daniel P. Berrangé wrote:
On Thu, Apr 14, 2022 at 02:46:38PM -0400, Tyler Fanelli 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
On 4/11/22 10:57 AM, Cole Robinson wrote: 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.
I see, then the use-case of postponing the validation until after VM launch doesn't make much sense for SEV/SEV-ES given that everything should be verified upfront.
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 ?
Realizing that my assumption of LAUNCH_MEASURE needing to be called while VM is paused is false, I tend to agree. With that in mind, what is the point of "query-sev-attestation-report" in QEMU? What was it's original purpose if it offers no real benefits compared to "query-sev-launch-measure"?
With regards, Daniel
-- Tyler Fanelli (tfanelli)