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

[Matthew Garrett <mjg59@google.com>]

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.

> >  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. 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, 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.

(While I work for Google, I'm not involved in crosvm development and
this shouldn't be interpreted as the position of anyone on that team)