Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP

From: James Bottomley <jejb@linux.ibm.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: linux-coco@lists.linux.dev, kvm@vger.kernel.org,
	amd-sev-snp@lists.suse.com
Subject: Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP
Date: Wed, 22 Mar 2023 17:53:08 -0400	[thread overview]
Message-ID: <4f07f72da5c73d317bb00e6b3c41f47090c5240b.camel@linux.ibm.com> (raw)
In-Reply-To: <ZBs/TX4eDuj5zc3+@work-vm>

On Wed, 2023-03-22 at 17:47 +0000, Dr. David Alan Gilbert wrote:
[...]
> > I think this might need to jump back to the vTPM protocol thread
> > since this is about COCONUT, but I'm worried we're talking about
> > AMD-specific long-term formats when perhaps the trusted computing
> > group should be widening its scope to how a TPM should be
> > virtualized. I appreciate that we're attempting to solve the
> > problem in the short term, and certainly the SVSM will need
> > attestation capabilities, but the linking to the TPM is dicey
> > without that conversation with TCG, IMHO.
> 
> Some standardisation of the link between the vTPM and the underlying
> CoCo hardware would be great; there's at least 2 or 3 CoCo linked
> vTPMs already and I don't think they're sharing any idea of that.

Well, for SNP, it's easy: the VMPL0 labelled attestation report proves
the SVSM and other components including OVMF and vTPM code
implementation.  We insert a hash of the manufactured EK into the
report and that gives proof from the trusted SVSM of the EK belonging
to the vTPM (essentially binding the vTPM to the VM).  The same thing
would work for other CoCo VM environments.

If we do ephemeral vTPMs, the binding is one time and there's no
persistent state security issue, so the SVSM-vTPM attestation is all
you need to begin trusting the vTPM measurements.

> Whether it's TCG I'm not sure; It doesn't seem to me to make sense
> for them to specify the flow to bring the vTPM up or the details of
> the underlying CoCo's attestation; but standardising how the two
> processes are tied together might be possible.

I think the TCG is probably not going to touch that because how you
attest the code that will run as the SVSM and vTPM is very specific to
each CoCo implementation.  However, they all provide a user data like
field which allows you to add information from the to be verified as
trusted SVSM, so you can use it for the EK, which is pretty identical
to the above proposal.

James