On 2/22/19 2:18 PM, James Bottomley wrote: > On Fri, 2019-02-22 at 14:00 -0800, David Tolnay wrote: >> On 2/22/19 7:30 AM, James Bottomley wrote: >>> On Thu, 2019-02-21 at 18:14 -0800, David Tolnay wrote: >>>> Add a config TCG_VIRTIO_VTPM which enables a driver providing the >>>> guest kernel side of TPM over virtio. >>> >>> What's the use case for using this over the current non-virtio >>> vTPM?. I always thought virtio was about guest to host transport >>> efficiency, but the phsical TPM, being connected over a very slow >>> bus, is about as inefficient as you can get in that regard, so why >>> do we need to use virtio to drive the virtual one? >>> >>>> Use case: TPM support is needed for performing trusted work from >>>> within a virtual machine launched by Chrome OS. >>> >>> The current vTPM does this, what's the use case for your special >>> one? >> >> Thanks James, these are important questions and the intention >> certainly isn't to have another driver that does the same thing with >> differences for no reason. >> >> I see three existing vTPM drivers already in drivers/char/tpm. >> >> - tpm_ibmvtpm, which is specific to PowerPC and implemented in terms >> of PowerPC hcalls. >> >> - xen-tpmfront, which is specific to Xen. >> >> - tpm_vtpm_proxy, which as I understand it is intended to enable >> userspace TPM. >> That is, if we are using this driver in a guest kernel, the TPM >> implementation >> also needs to reside in the guest kernel rather than in the >> hypervisor. >> >> For our use case which is not PowerPC and is running in our own >> hypervisor with the TPM needing to be provided by the hypervisor, >> none of the existing vTPM drivers seemed to fit the bill. >> >> Please let me know if I arrived at the wrong conclusion on this! > > Actually, yes, your third statement is not wholly correct: The in- > kernel vTPM proxy can certainly be used to emulate a TPM within a guest > for that guest to use without any support from the hypervisor. > However, when you have the correct qemu (requires a recent one), the > vTPM emulator can run in the host (or hypervisor) and be passed through > to the guest. The best description of how to do that seems to be this > blog entry: > > https://s3hh.wordpress.com/2018/06/03/tpm-2-0-in-qemu/ > > So won't this mode of operation exactly work for you (obviously with > necessary modifications to the crosvm hypervisor)? 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. 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. 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*. 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. 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. 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. Best, David
