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

[Stefan Berger]

"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.

> of having to manage all these extra processes alongside QEMU
> which can add a fair bit of mgmt overhead.

For libvirt, yes, there is mgmt. overhead but it's
quite transparent. So libvirt is involved in the creation of the directory
for the vTPMs, the command line creation for the external process as well
as the startup of the process, but otherwise it's not a big issue (anymore).
I have the patches that do just for an older libvirt version that along
with setting up SELinux labels, cgroups etc. for each VM that wants an
attached vTPM.

Regards,
   Stefan

> 
> > 
> > QEMU can then be started using the following parameters:
> > 
> > qemu-system-x86_64 \
> >    [...] \
> >         -tpmdev cuse-tpm,id=tpm0,cancel-path=/dev/null,path=/dev/vtpm-test
\
> >         -device tpm-tis,id=tpm0,tpmdev=tpm0
\
> >    [...]
> 
> 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:|
>