On Mon, 2019-02-25 at 14:24 -0800, Matthew Garrett wrote: > On Mon, Feb 25, 2019 at 2:14 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > 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-ov > > erlay/+/add5a4c3751778e5380f00b2ee6cebcb6bda48fc > > My understanding is that the crosvm USB code is intended to allow > arbitrary USB hardware to be passed through to the guest - doing this > via virtio sounds complicated (you'd need a virtio driver that > covered every USB class, and how would you manage that for devices > that are handled in userland at the moment), I think you'd need a virtio equivalent of the host driver, say xhci_virtio ... you could still use the in-kernel USB class drivers > whereas the virtio TPM support is intended to pass through a > software TPM rather than grant access to the host TPM. > > > 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. > > I don't really follow - how would in-kernel TPM features work then? If you do it at the TSS layer, then, of course, the kernel wouldn't participate. If you used the proposed in-kernel socsim driver, I suppose it could ... not that I'm advocating this, I'm saying if you want to minimise hypervisor code for attack surface reduction, this would be the way to do it because this solution requires no in- hypervisor code at all. James
