Re: SVSM vTPM specification

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

On Fri, 2022-10-21 at 07:54 -0400, Daniel P. Smith wrote:
> 
> On 10/16/22 12:44, James Bottomley wrote:
> > On Sun, 2022-10-16 at 12:29 -0400, Daniel P. Smith wrote:
> > > If enlightened guest/driver is acceptable, then why not adopt the
> > > pv-vTPM protocol, Xen's vTPM driver, for which there is already a
> > > driver present in the kernel, was designed for deep attestation,
> > > and does not inhibit/block features such as locality?
> > 
> > Erm, because it requires the Xen bus for discovery and
> > communication ... the KVM people might not be so keen on adding
> > that.  The other problem, even if we were to write a virtio
> > equivalent (which KVM doesn't have today because it relies on TIS
> > or CRB emulations), is that for all these virtual drivers, the back
> > endpoint is in the host and we want to terminate it in the SVSM,
> > which is the guest.
> 
> This is why I stated protocol and not transport. The Xen paravirt
> vTPM protocol is designed to go over a shared memory buffer using a
> doorbell notification, ie the transport mechanism under
> consideration. In addition the protocol defined a series of non-
> standard TPM command ordinals to interact with vTPM, more to deal
> with deep attestation. This approach could be leverage to access
> localities instead of trying to mimic a capability designed more for
> register access using a doorbell  which introduces the possibility of
> synchronicity issues. This work could then serve as a basis for a
> "Enlightened" vTPM TCG specification to enable cross-implementation
> compatibility.

The question under consideration was whether we could get an efficient
virtual TPM implementation for free (as in attach to an existing
driver).  The blocker to this for xen-tpmfront is the xenbus discovery.
If we're writing a new driver, we might as well do one that simply
attaches to the SVSM single call interface.  Since the CPU thread
passes into the VTPM and then returns with the result.  There's also no
current need to define non-standard ordinals, but if a need arises
nothing prevents layering them after the fact since they go down this
call interface.  This same is true of localities.  Since the locality
has to be deduced by the vTPM depending on environmental and physical
input nothing prevents them from being layered in later (when someone
figures out how to do localities in VMs).

> > To be clear, the current KVM drivers do emulate localites, it's
> > just that they're unused by the OS and Firmware.  If you look at
> > the TPM emulators themselves, they have the concept of locality,
> > but when they need it, they indirect via an additional platform
> > call (in the ms-tpm, which the current IBM prototype uses, it's a
> > stubbed call to __plat__LocalityGet/Set) ... the locality isn't
> > provided as part of the main TPM command processor, which is why we
> > don't need to worry about it in the initial prototype.  That means
> > if anyone ever does figure out how to do dynamic launch for virtual
> > machines, and requires localities, we can simply add handlers for
> > the stub routines.
> 
> Just as a last little 2₵, I would just highlight that the Mobile CRB 
> committee likely never considered that mobile processors like Arm
> would add a dynamic launch capability that would require the usage
> of localities. Yet today Arm now has a DRTM specification which is
> trying to deal with the fact that the Mobile CRB specification has no
> locality support. Sometimes making adjustments with forethought over
> expediency will save a lot of pain, like having to come up with
> migrations plans with minimal disruptions to customers because
> wholesale replacement of a solution becomes necessary for something
> that was known/raised at the  beginning.

The point of doing a CRB interface (if we do one) is to allow
attachment to an existing driver without too much trap overhead.  The
CRB interface is the one that fits this bill in the current linux
driver form regardless of what the design committee were or weren't
thinking.

You've studiously avoided sketching out what a dynamic launch might
look like for a confidential VM, but I'd have to guess it would be
facilitated and measured by the SVSM itself, being the trusted element.
Following this logic, anything written to the PCRs by the SVSM itself
would occur at a different locality from anything written through the
SVSM call interface ... the net result being only the SVSM could
control the privileged locality for the DRTM.  This would all work
regardless of the vagaries of the emulation presented beyond the SVSM.

James