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)
