Re: SVSM vTPM specification

[Dov Murik <dovmurik@linux.ibm.com>]

On 13/10/2022 22:20, James Bottomley wrote:
> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>> On 10/12/22 14:05, James Bottomley wrote:
>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>> ...
>>> It is theoretically possible to emulate a CRB TPM with just a
>>> single
>>> communication page and an ACPI entry (the Linux CRB driver is ACPI
>>> only
>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>
>>> The CRB device responds to a very compact MMIO region (0x30 bytes
>>> long)
>>> described in the CRB spec:
>>>
>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>>
>>> In theory we could use a page that keeps trapping to the SVSM for
>>> this,
>>> but the problem is that the CRB driver polls a register in the MMIO
>>> region to check command completion, so even a single TPM command is
>>> going to generate a huge number of such traps.  So while it's
>>> theoretically possible to generate a SVSM emulation of the CRB
>>> device,
>>> it would likely be too expensive in terms of traps, particularly if
>>> we're using the SVSM vTPM for runtime measurements like IMA.
>>>
>>> If we're going to do a new driver, I think basing it off the CRB
>>> spec
>>> would be fine (the spec envisages command request/response being
>>> via
>>> areas outside the MMIO region) and we could simply do a new driver
>>> that
>>> plumbs directly into the nine operations in the tpm_class_ops
>>> structure
>>>
>>
>> This sounds good. I think we can model an API call to the SVSM vTPM
>> using 
>> this. We can provide a struct that looks similar to the CRB Control
>> Area 
>> and supply the GPA of this struct in RCX to the SVSM for the vTPM to 
>> perform the operation:
>>
>>      - Command GPA
>>      - Command Size
>>      - Response GPA
>>      - Response Size
>>      - Status
> 
> Realistically, I think all TPM2 command/response actions can be packed
> into
> 
> u32 TPM2_action(u64 command_gpa, u32 command_len, u64 response_gpa, u32
> *response_len)
> 
> Where the u32 return would be the status (although if the SVSM has
> trouble with the return status, we could add it as an extra modified
> variable).
> 
> The way the current TPM driver interface works is shown in the
> tpm_class_ops structure:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/tpm.h
> 
> we can shim all the non-ignorable calls into the above.  The standard
> way of sending a command is tpm_try_transmit in
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm-interface.c
> 
> I think we can emulate an interrupt driven tpm (set TPM_CHIP_FLAG_IRQ
> in the driver) and it will simply do a ->send() ->receive() pair, which
> works for us since the thread of execution in ->send() will pass into
> the SVSM and return with the result which we can then copy over in
> ->recv

Yep, the ftpm driver [1] stores the TPM response at the end of ->send()
and then just copies it over in ->recv(), like you said.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ftpm_tee.c

> 
> Also note that tpm_try_transmit() uses the same buffer for send and
> receive, so it is possible to reduce the number of parameters in
> TPM2_action() above if that's the route people want to go.

I think that the leftover space in the SVSM's Calling Area (svsm_caa.svsm_buf:
4088 bytes) should be enough for the CRB struct and the command+response data buffer.
Using it might simplify the kernel driver a bit (reduce alloc/free calls).

-Dov


> 
>> Anything else that would go in the struct? Locality?
> 
> Well, this is a question.  CRB devices are actually allowed not to have
> a locality at all, so ignoring it is perfectly legal.  On the other
> hand, locality is used to allow or deny certain accesses. 
> Traditionally you allow firmware access at locality 4 as the trusted
> hardware component.  However, the problem with implementing localities
> is how does the SVSM know where we're calling from?  If it's unable to
> bar access at certain localities, there's not much point implementing
> them.  For reference the TIS TPM implements separate memory maps of its
> registers, one for each locality and firmware bars access to the OS by
> unmapping a range and refusing to allow the OS to map it back.
> 
> I suspect we'd get on faster by being pejorative and saying we won't
> implement locality since we can't police it.
> 
> James
>  
>