Re: SVSM vTPM specification

[Tom Lendacky <thomas.lendacky@amd.com>]

On 10/19/22 15:57, Dov Murik wrote:
> 
> 
> On 19/10/2022 17:43, 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)
> 
> NONCE size must be 32 (bytes)?
> or 31 if we use the initial type byte (See below).
> 
>>           - Report destination GPA (R8)
>>           - Report destination size (R9)
>>       - Output:
>>           - Result code (RAX)
>>
>>       NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
> 
> James suggested:
> 
> [511:504] - type byte 0x00 = vtpm attestation report
> [503:256] - 31 bytes nonce

Sound good.

> 
>>
>>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>>       MSG_REPORT_REQ:REPORT_DATA[255:0].
>>
>>       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
>>       (following the SVSM Core Protocol design of being additive).
> 
> 
> It's just a bit weird that the SNP attestation report function is part
> of the vTPM protocol; but I guess that it is needed so we can
> distinguish it from other future types of attestation reports (with
> James's suggested "type" byte, which must never be user-controlled; it
> must be set inside the SVSM).
> 
> 
> 
> Hmm, do we need also something like SNP_GET_EXT_REPORT which also
> returns the cert-chain stored in the host kernel? Or modify this call to
> also return the certs?

Yes, good catch. I believe we do. Adding two more parameters (maybe change 
this to a struct now?) for Cert Data GPA and Cert Data size is the way to 
go. We want the Cert Data that is associated with the attestation report 
that was generated, in an "atomic" way. Once live migration is available, 
the VM could theoretically be migrated in between two functions calls and 
then the VCEK wouldn't match.

Thanks,
Tom

> 
> 
> 
>>
>>    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.
>>
>> Are there any other functions that are needed?
>>
> 
> Looks good to me.  I think this is what we have in our prototype as well.
> 
> (But see my thought about equivalent of SNP_GET_EXT_REPORT.)
> 
> -Dov