Re: SVSM vTPM specification

[Stuart Yoder <stuart.yoder@arm.com>]

On 10/13/22 4:41 PM, James Bottomley wrote:
> On Thu, 2022-10-13 at 17:14 -0400, Daniel P. Smith wrote:
>> On 10/13/22 17:06, James Bottomley wrote:
>>> On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
>>>> 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.
>>>
>>> You mean the TIS interface:
>>>
>>> https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
>>>
>>> We discussed this at length with AMD ... which I think isn't
>>> captured in the email archives, unfortunately.  However, the bottom
>>> line is that TIS uses a FIFO approach to sending data through the
>>> MMIO page.  That's simply unscalable for pure emulation because it
>>> will result in 10-100x the number of write traps in the MMIO page
>>> as the CRB driver which uses a MMIO mailbox to trigger actions but
>>> passes the data via physical page addresses not FIFOs.
>>
>> Yes I am referring to the TIS interface but FIFO is only one of the
>> software interface defined in the spec. There is also the TIS CRB
>> interface which I should enable a similar experience as the mobile
>> CRB.
> 
> Well, not in the above spec there isn't, it's a pure FIFO.  I think you
> might be thinking of the PTP spec:
> 
> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
> 
> which defined locality mapping for the CRB interface (among other
> things).  But regardless of the TCG maze of slightly overlapping specs,
> I think you now agree we can't use the FIFO interface because of the
> high access trap overhead.  The outstanding question is over
> localities, but simply implementing the PTP multiple pages won't give
> us that.  It works for physical hardware because there's an motherboard
> implementation specific way of shutting off access to MMIO registers at
> a given locality.  We'd have to define such a thing for the SVSM ...
> but, as of today, it's not really properly defined for OVMF, indicating
> no-one's really using it as a security property for virtual
> environments.

Unless you expect to have some kind of virtual DRTM, all you need is
locality 0 in a virtual environment.

You could invent a new CRB-like interface, but how will it be 
advertised?  Through a new ACPI table definition that has to
get accepted by the UEFI Forum?  Updating the TCG ACPI spec?
And you will obviously need new drivers for each OS to be supported.

If you want to use a standard CRB and avoid overhead due to polling
in an MMIO interface you can implement the CRB interface completely in
normal DRAM, which is what is done for Trustzone-based firmware TPMs
on Arm.  The Mobile CRB spec specifically allows this. But, you will 
need a doorbell mechanism to signal the TPM to "start" operating on
a command that has been put in the CRB in DRAM.  The Linux CRB driver
works out of the box with this approach.

The standard TPM2 ACPI table could be used and all you need to define
is a new start method.

There are tradeoffs for both approaches.

Thanks,
Stuart