Re: SVSM vTPM specification

[James Bottomley <jejb@linux.ibm.com>]

On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
[...]
> > What would an enlightened guest need from the SVSM for attestation
> > of the SVSM/vTPM? What would a vTPM driver need to supply to an
> > SVSM for TPM operations?
> > 
> > For attestation, the SVSM could provide a VMPCK0 attestation
> > report. What, if any, data should the guest supply to the SVSM to
> > be part of the SNP attestation report data? Should this attestation
> > request be part of the SVSM base protocol?
> 
> I'm not quite sure what a 'VMPCK0 attestation report' is?
> It's important that the VMPL level in the attestation report reflects
> the side asking for the attestation; in particular one TPM story goes
> that the firmware (in VMPL0) would ask for an attestation and the
> attestor would return the vTPM stored state.  It's important that the
> state could only be returned to the vTPM not the guest, so the
> attestor would check that the VMPL level in the attestation was 0;
> any guest attestation would have a VMPL>0 and so the attestor
> wouldn't hand it the vTPM state.
> Hmm or are you saying such a report would be triggered by the guest
> rather than the firmware, but it would be protected by VMPCK0 so the
> guest wouldn't be able to read it?
> 
> I think one of the vTPMs keys should be in the SNP attestation report
> (the EK???) - I think that would allow you to attest that the vTPM
> you're talking to is a vTPM running in an SNP protected firmware.

Traditionally the TPM identity is the public EK, so that should
definitely be in the report.  Ideally, I think the public storage root
key (key derived from the owner seed) should be in there two because it
makes it easy to create keys that can only be read by the TPM (keys
should be in the owner hierarchy which means they have to be encrypted
to the storage seed, so we need to know what a public key corresponding
to it is).

One wrinkle of the above is that, when provisioned, the TPM will only
have the seeds, not the keys (the keys are derived from the seeds via a
TPM2_CreatePrimary command).  The current TPM provisioning guidance:

https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/

Says that the EK should be at permanent handle

81010001

And there's an update saying that should be the RSA-2048 key and there
should be an EC (NIST-P256) one at 81010002.  The corresponding storage
keys should be at 81000001 and 81000002 respectively.  I think when the
SVSM provisions the TPM, it should run TPM2_CreatePrimary for those
four keys and put them into the persistent indexes, then insert the EC
keys only for EK and SRK into the attestation report.

James