Re: SVSM vTPM specification

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

On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
> I'd be inclined to not rely on guest networking, and probably even
> strictly decouple what the SVSM does to communicate, from any
> specific attestation server connection protocol or details.

I think we should be clear: if you need a secret at start of day,
before the guest boots, then you need to retrieve an attestation from
the SVSM and inject a secret.  If you can delay needing the secret
until after boot (say for data volumes) then you can use the cloud
standard methods we have today (which actually do mostly operate over
the guest network path) and a TPM which manufactures on boot.

However, the above mechanism is out of scope for the vTPM project. 
This is simply about putting a vTPM into the SVSM which appears in the
guest as a TPM and providing a guest API to retrieve its attestation. 
So the scope of the project ends there.

If we want a TPM with persistent state, then the state has to be
injected pre-boot but that is the same pre-boot problem as all secret
injection.  I think there should be a separate project working on this
and we'll make sure they interlock correctly.

So I think there are three pieces

   1. Ephemeral vTPM with attestation retrieved from guest
   2. Attestation and injection API from SVSM to host/guest end point
   3. SVSM API for saving TPM state

We'll work initially on 1. Someone else can work on 2. but we'll make
sure they fit together.  3. would be required for full TPM emulation,
but might not be required if all we want is persistence of the seeds of
the TPM, so this would be evaluated when we have 1+2.

James