On Mon, 2019-02-25 at 14:43 -0800, Matthew Garrett wrote: > On Mon, Feb 25, 2019 at 2:32 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2019-02-25 at 14:24 -0800, Matthew Garrett wrote: > > > 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 > > Mm. I honestly don't know enough about the desired use case for USB > to be able to provide meaningful input here. > > > > > 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. > > You still need a transport mechanism through the hypervisor to > communicate with the host - what would you be using in that case > instead of virtio? Socsim is net transported; it's sort of the TPM equivalent of NFS or iSCSI storage for guests. James
