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

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Mar 01, 2017 at 08:25:43AM -0500, Stefan Berger wrote:
> "Daniel P. Berrange" <berrange@redhat.com> wrote on 03/01/2017 07:54:14 
> AM:
> 
> > From: "Daniel P. Berrange" <berrange@redhat.com>
> > To: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Stefan Berger/
> > Watson/IBM@IBMUS, "mst@redhat.com" <mst@redhat.com>, "qemu-
> > devel@nongnu.org" <qemu-devel@nongnu.org>, "SERBAN, CRISTINA" 
> > <cs1731@att.com>, "Xu, Quan" <quan.xu@intel.com>, 
> > "silviu.vlasceanu@gmail.com" <silviu.vlasceanu@gmail.com>, 
> > "hagen.lauer@huawei.com" <hagen.lauer@huawei.com>, "SHIH, CHING C" 
> > <cs1815@att.com>
> > Date: 03/01/2017 08:03 AM
> > Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE 
> TPM
> > 
> > On Wed, Mar 01, 2017 at 07:25:28AM -0500, Stefan Berger wrote:
> > > On 06/16/2016 04:25 AM, Daniel P. Berrange wrote:
> > > > On Thu, Jun 16, 2016 at 09:05:20AM +0100, Dr. David Alan Gilbert 
> wrote:
> > > > > * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
> > > > > > On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote:
> > > > > <snip>
> > > > > 
> > > > > > > So what was the multi-instance vTPM proxy driver patch set 
> about?
> > > > > > That's for containers.
> > > > > Why have the two mechanisms? Can you explain how the 
> multi-instance
> > > > > proxy works; my brief reading when I saw your patch series seemed
> > > > > to suggest it could be used instead of CUSE for the non-container 
> case.
> > > > One of the key things that was/is not appealing about this CUSE 
> approach
> > > > is that it basically invents a new ioctl() mechanism for talking to
> > > > a TPM chardev. With in-kernel vTPM support, QEMU probably doesn't 
> need
> > > > to have any changes at all - its existing driver for talking to TPM
> > > 
> > > We still need the control channel with the vTPM to reset it upon VM 
> reset,
> > > for getting and setting the state of the vTPM upon 
> snapshot/suspend/resume,
> > > changing locality, etc.
> > 
> > You ultimately need the same mechanisms if using in-kernel vTPM with
> > containers as containers can support snapshot/suspend/resume/etc too.
> 
> The vTPM running on the backend side of the vTPM proxy driver is 
> essentially the same as the CUSE TPM used for QEMU. I has the same control 
> channel through sockets. So on that level we would have support for the 
> operations but not integrated with anything that would support container 
> migration.

This goes back to the question Dave mentions above ? Ignoring the control
channel aspect temporarily, can the CUSE TPM support the exact same ioctl
interface as the existing kernel TPM device ? It feels like this should
be possible, and if so, then this virtal TPM feature can be considered to
have two separate pieces.

First enabling basic CUSE TPM device support would not require QEMU changes,
as we could just use the existing tpm-passthrough driver against the CUSE
device, albeit with the limitations around migration, snapshot etc.

Second we could consider the question of supporting a control channel as
a separate topic. IIUC, QEMU essentially needs a way to trigger various
operations in the underlying TPM implementation, when certain lifecycle
operations are performed on the VM. I could see this being done as a
simple network protocol over a UNIX socket. So, you could then add a
new 'chardev' property to the tpm-passthrough device, which gives the
ID of a character device that provides the control channel.

This way QEMU does not need to have any special code to deal with CUSE
directly. QEMU could be used with a real TPM device, a vTPM device or
a CUSE TPM device, with the same driver. With both the vTPM and the
CUSE TPM device, QEMU would have the ability to use a out of band
control channel when migration/snapshot/etc take place.

This cleanly isolates QEMU from the particular design & implementation
that is currently used by the current swtpm code.

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