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

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Matthew Garrett <mjg59@google.com>,
	David Tolnay <dtolnay@gmail.com>, Peter Huewe <peterhuewe@gmx.de>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	linux-integrity <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: Mon, 25 Feb 2019 14:24:51 -0800	[thread overview]
Message-ID: <1551133491.3226.75.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190225210511.GA8727@linux.intel.com>

On Mon, 2019-02-25 at 23:05 +0200, Jarkko Sakkinen wrote:
> On Mon, Feb 25, 2019 at 12:20:43PM -0800, James Bottomley wrote:
> > On Mon, 2019-02-25 at 11:17 -0800, Matthew Garrett wrote:
> > > On Mon, Feb 25, 2019 at 7:36 AM James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > > The virtio driver performs discovery via virtio, which crosvm
> > > > > implements already for all of its supported devices. This
> > > > > substantially reduces the amount of TPM-specific code
> > > > > compared to your suggestions, and lowers the barrier to entry
> > > > > for implementing TPM support in other hypervisors which I
> > > > > hope we agree is beneficial.
> > > > 
> > > > Well, that's somewhat misleading:  The reason we already have
> > > > two hypervisor specific drivers already is because every
> > > > hypervisor has a different  virtual discovery mechanism. You
> > > > didn't find the other two hypervisor drivers remotely useful,
> > > > so why would another hypervisor find yours useful?
> > > 
> > >  
> > > The existing hypervisor drivers expose hypervisor-specific
> > > details. This proposed driver provides an abstract interface that
> > > is usable by other hypervisors. It allows building a VM that
> > > exposes TPM functionality without requiring additional hardware
> > > emulation, reducing the hypervisor attack surface.
> > 
> > Well, that depends whether you think a virtio bus is an abstract
> > concept or a hypervisor specific detail.  There are currently four
> > major hypervisors: xen, kvm, hyper-v and ESX.  Of those, only one
> > implements virtio: kvm.  I agree virtio is a standard and certainly
> > a slew of minor hypervisors implement it because they need paravirt
> > support on Linux so they piggyback off kvm, but I don't see any of
> > the other major hypervisors jumping on the bandwagon.
> > 
> > I certainly agree our lives would be easier if all the major
> > hypervisor vendors would just agree a single paravirt driver
> > standard.
> 
> I think that a Windows hypervisor (Hyper-V) and a closed hypervisor
> (VMWare) are out of context for this discussion.

But why?  We already have both in various Linux subsystems; for
instance SCSI has storvsc (hyper-v paravirt storage driver) and
vmw_pvscsi (VMWare paravirt storage dirver).  The only real requirement
is a willingness to open source the driver and publish the
communication spec.  If another paravirt TPM driver is a good idea, why
wouldn't we allow these guys to play in our sandpit too (under the
right open source conditions, of course)?

James