Re: [PATCH] tpm: Add driver for TPM over virtio

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Tolnay <dtolnay@gmail.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	linux-integrity@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	virtualization@lists.linux-foundation.org, dgreid@chromium.org,
	apronin@chromium.org
Subject: Re: [PATCH] tpm: Add driver for TPM over virtio
Date: Fri, 22 Feb 2019 14:18:20 -0800	[thread overview]
Message-ID: <1550873900.2787.25.camel@HansenPartnership.com> (raw)
In-Reply-To: <e0284af7-be61-6a0f-8df6-a0d646577258@gmail.com>

On Fri, 2019-02-22 at 14:00 -0800, David Tolnay wrote:
> On 2/22/19 7:30 AM, James Bottomley wrote:
> > On Thu, 2019-02-21 at 18:14 -0800, David Tolnay wrote:
> > > Add a config TCG_VIRTIO_VTPM which enables a driver providing the
> > > guest kernel side of TPM over virtio.
> > 
> > What's the use case for using this over the current non-virtio
> > vTPM?. I always thought virtio was about guest to host transport
> > efficiency, but the phsical TPM, being connected over a very slow
> > bus, is about as inefficient as you can get in that regard, so why
> > do we need to use virtio to drive the virtual one?
> > 
> > > Use case: TPM support is needed for performing trusted work from
> > > within a virtual machine launched by Chrome OS.
> > 
> > The current vTPM does this, what's the use case for your special
> > one?
> 
> Thanks James, these are important questions and the intention
> certainly isn't to have another driver that does the same thing with
> differences for no reason.
> 
> I see three existing vTPM drivers already in drivers/char/tpm.
> 
> - tpm_ibmvtpm, which is specific to PowerPC and implemented in terms
> of PowerPC hcalls.
> 
> - xen-tpmfront, which is specific to Xen.
> 
> - tpm_vtpm_proxy, which as I understand it is intended to enable
> userspace TPM.
>   That is, if we are using this driver in a guest kernel, the TPM
> implementation
>   also needs to reside in the guest kernel rather than in the
> hypervisor.
> 
> For our use case which is not PowerPC and is running in our own
> hypervisor with the TPM needing to be provided by the hypervisor,
> none of the existing vTPM drivers seemed to fit the bill.
> 
> Please let me know if I arrived at the wrong conclusion on this!

Actually, yes, your third statement is not wholly correct:  The in-
kernel vTPM proxy can certainly be used to emulate a TPM within a guest
for that guest to use without any support from the hypervisor. 
However, when you have the correct qemu (requires a recent one), the
vTPM emulator can run in the host (or hypervisor) and be passed through
to the guest.  The best description of how to do that seems to be this
blog entry:

https://s3hh.wordpress.com/2018/06/03/tpm-2-0-in-qemu/

So won't this mode of operation exactly work for you (obviously with
necessary modifications to the crosvm hypervisor)?

James