Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

[Daniel P. Berrange]

On Wed, Jan 20, 2016 at 10:31:56AM -0500, Stefan Berger wrote:
> "Daniel P. Berrange" <address@hidden> wrote on 01/20/2016 10:00:41 
> AM:
> 
> > Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE 
> TPM
> > 
> > On Mon, Jan 04, 2016 at 10:23:19AM -0500, Stefan Berger wrote:
> > > From: Stefan Berger <address@hidden>
> > > 
> > > Rather than integrating TPM functionality into QEMU directly
> > > using the TPM emulation of libtpms, we now integrate an external
> > > emulated TPM device. This device is expected to implement a Linux
> > > CUSE interface (CUSE = character device in userspace).
> > > 
> > > QEMU talks to the CUSE TPM using much functionality of the
> > > passthrough driver. For example, the TPM commands and responses
> > > are sent to the CUSE TPM using the read()/write() interface.
> > > However, some out-of-band control needs to be done using the CUSE
> > > TPM's ioctls. The CUSE TPM currently defines and implements 15
> > > different ioctls for controlling certain life-cycle aspects of
> > > the emulated TPM. The ioctls can be regarded as a replacement for
> > > direct function calls to a TPM emulator if the TPM were to be
> > > directly integrated into QEMU.
> > > 
> > > One of the ioctls allows to get a bitmask of supported capabilities.
> > > Each returned bit indicates which capabilities have been implemented.
> > > An include file defining the various ioctls is added to QEMU.
> > > 
> > > The CUSE TPM and associated tools can be found here:
> > > 
> > > https://github.com/stefanberger/swtpm
> > > 
> > > (please use the latest version)
> > > 
> > > To use the external CUSE TPM, the CUSE TPM should be started as 
> follows:
> > > 
> > > # terminate previously started CUSE TPM
> > > /usr/bin/swtpm_ioctl -s /dev/vtpm-test
> > > 
> > > # start CUSE TPM
> > > /usr/bin/swtpm_cuse -n vtpm-test
> > 
> > IIUC, there needs to be one swtpm_cuse process running per QEMU
> > TPM device ?  This makes my wonder why we need this separate
> 
> Correct. See reason in answer to previous email.
> 
> > 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


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|