Re: SVSM vTPM specification

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

On Wed, 2022-10-19 at 09:43 -0500, Tom Lendacky wrote:
> On 10/19/22 08:05, Daniel P. Berrangé wrote:
> > On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
> > > 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.
> > 
> > Yes, that all makes sense to me as a division of concepts & work.
> 
> There was some offline talk about possibly putting the attestation
> report in the TPM NV area and allowing it to be pulled via TPM
> commands. However,  if we want to be able to supply a new NONCE each
> time, I think, instead, that calls for it's own function in the SVSM
> vTPM protocol.
> 
> Currently, there are two functions in the vTPM protocol:
> 
>    1. An attestation report function
>       - Input:
>           - NONCE GPA (RCX)
>           - NONCE size (RDX)
>           - Report destination GPA (R8)
>           - Report destination size (R9)
>       - Output:
>           - Result code (RAX)
> 
>       NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
> 
>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>       MSG_REPORT_REQ:REPORT_DATA[255:0].

You still have to define *which* public key here.  Recall the TPM
internally has a seed.  First you have to derive the public key from
that seed.  I'd still favour using the NIST-P256 derivation of the
public key according to the TCG template, because NIST is going to
deprecate RSA-2048 at some point.

> 
>       On success, the report is present at Report Destination GPA.
> 
>       If a new way of creating REPORT_DATA is needed in the future,
> the
>       protocol could be extended with a new attestation report
> function


One thing we have to remember is that if we add any additional
attestation APIs, they can't allow them ever be used to generate a
report that looks like a vTPM attestation.  So if that's likely we'll
need multiple types of data put into the report, should we steal a byte
of the report data to specify what type of report (0 for TPM, 1 for the
next type and so on).

That way a consumer could rely on the fact that if the first byte was 0
this must be a vTPM report and nothing else could fake it.

>    2. A vTPM operation function
>       - Input:
>           - Command GPA (RCX)
>           - Command size (RDX)
>           - Response GPA (R8)
>           - Response size (R9)
>       - Output:
>           - Result code (RAX)
> 
>       On success, the result is present at Response GPA.
> 
>       @James Bottomley, I noticed in an earlier response that you had
> the
>       Response size as a possible output, is that needed? The
> response
>       output (header) contains the actual length of the response.

I think we can get away with just command GPA and size and put the
response back into the command buffer, given that's the way the linux
driver will work.  We will still need to return the response size since
it may be less than the command size.  I think the function definition
will have to specify that at least a page is available for writing at
RCX so we can cope with response size > command size.  The current ms
tpm defines the values MAX_COMMAND_SIZE and MAX_RESPONSE_SIZE and
they're currently hard coded to 4096, so we can rely on this value for
a while.

James