On Fri, 2019-02-22 at 16:45 -0800, David Tolnay wrote: [...] > I appreciate the explanation and link, James! > > I had briefly investigated the existing support in QEMU before > pursuing a virtio based driver. At the time, I determined that QEMU > implements a register level emulation of a TPM rather than what our > team would consider a minimum viable vTPM. Actually, no, it doesn't at all. QEMU implements nothing about a TPM. You have to set up a software TPM outside of qemu which talks over a socket and then use the vTPM socket to pass that TPM through to qemu. Effectively QEMU is TPM implementation blind (which is why it can do both 1.2 and 2.0) all it provides is discovery of the virtual hardware. > It implements the TPM-specific TIS interface (QEMU's tpm_tis.c) as > well as CRB interface (QEMU's tpm_crb.c) which require Linux's TIS > driver (Linux's tpm_tis.c) and CRB driver (Linux's tpm_crb.c) > respectively. Both of those are based on ACPI. That's right, QEMU implements the device interface emulation, but it passes the actual TPM communication packets to the vTPM outside QEMU. > As far as I can tell, QEMU does not provide a mode in which the > tpm_vtpm_proxy driver would be involved *in the guest*. It doesn't need to. the vTPM proxy can itself do all of that using the guest Linux kernel. There's no hypervisor or host involvement. This is analagous to the vTPM for container use case, except that to get both running in a guest you'd use no containment, so the vtpm client and server run in the guest together: https://www.kernel.org/doc/html/v4.16/security/tpm/tpm_vtpm_proxy.html > Certainly you could use a vtpm proxy driver *on the host* but would > still need some other TPM driver running in the guest for > communication with the host, possibly virtio. If this second approach > is what you have in mind, let me know but I don't think it is > applicable to the Chrome OS use case. Actually, the vTPM on-host use case doesn't use the in kernel vtpm proxy driver, it uses a plain unix socket. That's what the original website tried to explain: you set up swtpm in socket mode, you point the qemu tpm emulation at the socket and you boot up your guest. > Clearly it's possible for us to go the QEMU route and implement ACPI > (which crosvm does not otherwise need) plus one or both of TIS and > CRB in crosvm, but since all we need is for TPM command buffers to > leave the VM and TPM response buffers to enter the VM, all of that > seems unnecessarily complicated. A virtio driver substantially > lowers the barrier to implementing a hypervisor vTPM. I don't believe it requires ACPI, that's just one common way of enumerating TPMs and it's how the guest finds it. If you implemented the QEMU passthrough in crosvm, you could use whatever mechanism that's convenient to you and would cause a TPM driver to bind. It's the QEMU layer that provides the virtual hardware emulation for the device and the external vTPM that provides the TPM implementation. The two are completely decoupled. Are you saying crosvm has no ability at all to emulate the discovery that we use in the kernel to find TPMs? Is it some type of firecracker like think that only supports fully emulated devices? > Separately, I'd be curious whether you share Jason Gunthorpe's > opinion stated elsewhere in the thread, or whether you would > encourage the virtio TPM driver to be kept private if feasible > alternative drivers already exist. Jason's comment: > > > We already have a xen 'virtioish' TPM driver, so I don't think > > there is a good reason to block a virtio driver if someone cares > > about it. There are enough good reasons to prefer virtio to other > > options, IMHO. I've no real opinion on that one until I understand why you went down this path instead of using existing implementations. Right at the moment I do get the impression its because you didn't know how the existing implementations worked. James
