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

On 4/20/22 5:45 AM, Daniel P. Berrangé wrote: > > > 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"?