[RFC PATCH v1 0/5] Add virDomainGetSevAttestationReport API

[Tyler Fanelli]

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

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)