* BICKFORD, JEFFREY E (jb6...@att.com) wrote: > > * Daniel P. Berrange (berra...@redhat.com) wrote: > > > On Wed, Jan 20, 2016 at 10:54:47AM -0500, Stefan Berger wrote: > > > > On 01/20/2016 10:46 AM, Daniel P. Berrange wrote: > > > > >On Wed, Jan 20, 2016 at 10:31:56AM -0500, Stefan Berger wrote: > > > > >>"Daniel P. Berrange" <berra...@redhat.com> wrote on 01/20/2016 > > > > >>10:00:41 > > > > >>AM: > > > > >> > > > > >> > > > > >>>process at all - it would make sense if there was a single > > > > >>>swtpm_cuse shared across all QEMU's, but if there's one per > > > > >>>QEMU device, it feels like it'd be much simpler to just have > > > > >>>the functionality linked in QEMU. That avoids the problem > > > > >>I tried having it linked in QEMU before. It was basically rejected. > > > > >I remember an impl you did many years(?) ago now, but don't recall > > > > >the results of the discussion. Can you elaborate on why it was > > > > >rejected as an approach ? It just doesn't make much sense to me > > > > >to have to create an external daemon, a CUSE device and comms > > > > >protocol, simply to be able to read/write a plain file containing > > > > >the TPM state. Its massive over engineering IMHO and adding way > > > > >more complexity and thus scope for failure > > > > > > > > The TPM 1.2 implementation adds 10s of thousands of lines of code. The > > > > TPM 2 > > > > implementation is in the same range. The concern was having this code > > > > right > > > > in the QEMU address space. It's big, it can have bugs, so we don't want > > > > it > > > > to harm QEMU. So we now put this into an external process implemented > > > > by the > > > > swtpm project that builds on libtpms which provides TPM 1.2 > > > > functionality > > > > (to be extended with TPM 2). We cannot call APIs of libtpms directly > > > > anymore, so we need a control channel, which is implemented through > > > > ioctls > > > > on the CUSE device. > > > > > > Ok, the security separation concern does make some sense. The use of CUSE > > > still seems fairly questionable to me. CUSE makes sense if you want to > > > provide a drop-in replacement for the kernel TPM device driver, which > > > would avoid ned for a new QEMU backend. If you're not emulating an > > > existing > > > kernel driver ABI though, CUSE + ioctl is feels like a really awful RPC > > > transport between 2 userspace processes. > > > While I don't really like CUSE; I can see some of the reasoning here. > > By providing the existing TPM ioctl interface I think it means you can use > > existing host-side TPM tools to initialise/query the soft-tpm, and those > > should be independent of the soft-tpm implementation. > > As for the extra interfaces you need because it's a soft-tpm to set it up, > > once you've already got that ioctl interface as above, then it seems to make > > sense to extend that to add the extra interfaces needed. The only thing > > you have to watch for there are that the extra interfaces don't clash > > with any future kernel ioctl extensions, and that the interface defined > > is generic enough for different soft-tpm implementations. > > > Dave > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > Over the past several months, AT&T Security Research has been testing the > Virtual TPM software from IBM on the Power (ppc64) platform. Based on our > testing results, the vTPM software works well and as expected. Support for > libvirt and the CUSE TPM allows us to create VMs with the vTPM functionality > and was tested in a full-fledged OpenStack environment. > > We believe the vTPM functionality will improve various aspects of VM security > in our enterprise-grade cloud environment. AT&T would like to see these > patches accepted into the QEMU community as the default-standard build so > this technology can be easily adopted in various open source cloud > deployments.
Interesting; however, I see Stefan has been contributing other kernel patches that create a different vTPM setup without the use of CUSE; if that's the case then I guess that's the preferable solution. Jeffrey: Can you detail a bit more about your setup, and how you're maanging the life cycle of the vTPM data? Dave > > Regards, > Jeffrey Bickford > AT&T Security Research Center > jbickf...@att.com -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
