Re: SVSM vTPM specification

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

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.

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.

James