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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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.

> > >  For me as a hypervisor implementer, what advantages do you see
> > > that would make me decide to implement TPM-specific virtual
> > > hardware emulation in the form of TIS rather than simply
> > > leveraging a virtio driver like for other virtual devices?
> > 
> > So your argument is that for every device we have in the Linux
> > kernel, we should have the N hypervisor paravirt variants for the
> > same thing? I assure you that's not going to fly because paravirt
> > drivers would then outnumber real drivers by an order of magnitude.
> 
> Well, no - in general there's no need to have more than one virtio
> driver for any /class/ of hardware. For various unfortunate accidents
> of history we've ended up with multiple cases where we have
> hypervisor-specific drivers.

Fully agree, that's why I'm doing so now.

>  Using the more generic virtio
> infrastructure reduces the need for that, since any hypervisor should
> be able to implement the backend (eg, in this case it'd be very easy
> to add support for this driver to qemu,

I certainly agree there ... is there a plan for this?

>  which would allow the use of TPMs without needing to enable a whole
> bunch of additional qemu features). This isn't a discussion we'd be
> having if we'd pushed back more strongly against hypervisor-specific
> solutions in the past.

I'm still looking for the pragmatic use case.  I think yours is attack
surface reduction, because the virtio discovery and operation is less
code and therefore more secure than physical hardware discovery and
operation?  I'm not entirely sure I buy that because the TPM
communication interface is pretty simple and it's fairly deep down in
the kernel internal stack making it difficult to exploit.

James