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

[Matthew Garrett <mjg59@google.com>]

On Mon, Feb 25, 2019 at 12:20 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2019-02-25 at 11:17 -0800, Matthew Garrett wrote:
> > 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.

Is there any technical issue preventing virtio working with Xen?
Running HVM guests under qemu ought to allow virtio to work.

> > 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?

I don't know, but I can see the value in making testing easier.

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

Being able to get away without any LPC support code at all seems like
a win, as does not having any ACPI or DeviceTree parsing code.
Injecting the hardware information via the kernel command line isn't
impossible, but it's not an attractive solution.