Re: SVSM vTPM specification

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

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

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.

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

James