Re: SVSM vTPM specification

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

Pardon the interjection.

On 10/13/22 15: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/

IMHO I would not use the mobile CRB, which was designed as a doorbell 
solution for ARM where trapping a page was not possible. Since it is 
possible to trap on page access, this makes it possible to implement the 
PC Client MMIO interface and enables implementations to provide the 
complete set of TPM capabilities, e.g. localities.

>>> 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
> 
> 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.
> 
>> 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.

If a guest were to attempt the SKINIT instruction, it should result in a 
NAE VMEXIT with reason being SKINIT. I haven't looked in-depth at VMPLs 
in detail yet but I would like to believe this would provide the 
necessary context of who made the call.

This is of particular interest to the TrenchBoot community as we have 
long had on our roadmap the desire to provide vDRTM for guests that is 
coupled with vTPM instances to provide for nested/deep attestation.

> I suspect we'd get on faster by being pejorative and saying we won't
> implement locality since we can't police it.
> 
> James

V/r,
Daniel