On Mon, 2019-02-25 at 23:05 +0200, Jarkko Sakkinen wrote: > On Mon, Feb 25, 2019 at 12:20:43PM -0800, James Bottomley wrote: > > On Mon, 2019-02-25 at 11:17 -0800, Matthew Garrett wrote: > > > On Mon, Feb 25, 2019 at 7:36 AM James Bottomley > > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > The virtio driver performs discovery via virtio, which crosvm > > > > > implements already for all of its supported devices. This > > > > > substantially reduces the amount of TPM-specific code > > > > > compared to your suggestions, and lowers the barrier to entry > > > > > for implementing TPM support in other hypervisors which I > > > > > hope we agree is beneficial. > > > > > > > > Well, that's somewhat misleading: The reason we already have > > > > two hypervisor specific drivers already is because every > > > > hypervisor has a different virtual discovery mechanism. You > > > > didn't find the other two hypervisor drivers remotely useful, > > > > so why would another hypervisor find yours useful? > > > > > > > > > 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. > > > > I certainly agree our lives would be easier if all the major > > hypervisor vendors would just agree a single paravirt driver > > standard. > > I think that a Windows hypervisor (Hyper-V) and a closed hypervisor > (VMWare) are out of context for this discussion. But why? We already have both in various Linux subsystems; for instance SCSI has storvsc (hyper-v paravirt storage driver) and vmw_pvscsi (VMWare paravirt storage dirver). The only real requirement is a willingness to open source the driver and publish the communication spec. If another paravirt TPM driver is a good idea, why wouldn't we allow these guys to play in our sandpit too (under the right open source conditions, of course)? James
