On Mon, 2019-02-25 at 13:00 -0800, Matthew Garrett wrote: > On Mon, Feb 25, 2019 at 12:20 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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. Other than developer resistance because xenbus was "first" not really, I think. There was even a GSOC student who tried it: https://wiki.xenproject.org/wiki/Virtio_On_Xen > > > 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. Having at least a commitment to qemu support does make the case stronger. > > > 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. Heh, but isn't that exactly what crosvm did for usb: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/add5a4c3751778e5380f00b2ee6cebcb6bda48fc Effectively it bypasses the hypervisor altogether and simply makes a direct connection to the host devices. The TPM could actually work in exactly the same way, except you'd have to use the socsim IP connection (which all TSSs support) rather than a file descriptor. James
