Re: SVSM vTPM specification

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Tom Lendacky (thomas.lendacky@amd.com) wrote:
> I'd like to approach this from the standpoint of an enlightened guest with a
> TPM driver that is SVSM aware. I'm by no means a TPM expert, but I'll pose a
> bunch of questions to see if we can start moving forward.

Thanks for starting the discussion off.

> 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.

> For the TPM, is it enough to emulate the TPM device register space? Rather
> than using a PCI BAR or an ACPI memory resource address, could the vTPM
> driver replicate the TPM register space in ordinary memory for the SVSM to
> process? Should this memory come from the SVSM or from the guest?
> 
> Or is there a better, more efficient method that can be used to perform TPM
> operations? What would that look like?

Can we make this look as close to the TPM CRB as possible; from
discussions with others it looks clear something extra is needed; but I
don't see the reason to be too inventive.

Dave

> Here's hoping this starts the discussion...
> 
> Thanks,
> Tom
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK