Re: [Qemu-devel] [PATCH v4 0/4] Extend TPM support with a QEMU-external TPM

[Stefan Berger]

"Michael S. Tsirkin" <address@hidden>
wrote on 06/23/2015 01:26:13 AM:

> From: "Michael S. Tsirkin" <address@hidden>
> To: Stefan Berger <address@hidden>
> Cc: address@hidden, address@hidden,
Stefan Berger/Watson/address@hidden
> Date: 06/23/2015 01:26 AM
> Subject: Re: [PATCH v4 0/4] Extend TPM support
with a QEMU-external TPM
> 
> On Mon, Jun 08, 2015 at 07:17:33AM -0400, Stefan Berger wrote:
> > The following series of patches extends TPM support with an
> > external TPM that offers a Linux CUSE (character device in userspace)
> > interface. This TPM lets each VM access its own private vTPM.
> > The CUSE TPM supports suspend/resume and migration. Much
> > out-of-band functionality necessary to control the CUSE TPM is
> > implemented using ioctls.
> 
> I was hoping this can get a wider discussion, but apparently no one
> noticed this.
> 
> This needs some thought: how do we decide which ioctls we support?

The ioctls the patches are currently using support
all necessary aspects for controlling that
external TPM following interaction with the TPM TIS
emulation (tpm_tis.c) and
virtual machine migration. [Excluding support for
DRTM]

There's an ioctl that returns a bitfield of supported
features. The patches use the ioctl
to determine whether enough features are supported
to for example support migration.
A supported feature then means supporting its corresponding
ioctl and associated data structure.

> It's easier with kernel since we know distros ship it, but
> will they do so with this tpm? We do want to reuse system components

I haven't packaged the swtpm for Fedora (for example)
yet. I wanted to delay the tagging of version 0.1
of swtpm until the code that's using it is in QEMU.


> but we don't want random parts of QEMU delegated to a random
> out of tree module.

It's hopefully not that random. There's nothing comparable
out there. Just having the TPM passthrough
isn't useful. Usefulness comes with the CUSE TPM driver
and external CUSE TPM, since this provides a
private and fully functional TPM to each QEMU VM.

> 
> Couldn't you re-use in-kernel interfaces for the CUSE module?

The CUSE TPM uses the ioctl's for out-of-band control.
The out-of-band control happens on a different
level than what is out there in the kernel right now,
since we are implementing a layer that is 
typically implemented in hardware. Otherwise I am
not sure what re-use of in-kernel interfaces you
are referring to.


> Then existing pass-through in QEMU would more or less just work with
it -
> merely open a different chardev.

Having implemented 10+ ioctls for out-of-band control
shows a necessity for out-of-band control.
It is not enough to support a read()/write() interface
where we can send TPM request through.

   Stefan

> 
> 
> > Stefan Berger (4):
> >   Provide support for the CUSE TPM
> >   Introduce condition to notify waiters of completed command
> >   Introduce condition in TPM backend for notification
> >   Add support for VM suspend/resume for TPM TIS
> > 
> >  hmp.c              
         |   6 +
> >  hw/tpm/tpm_int.h            
|   4 +
> >  hw/tpm/tpm_ioctl.h           |
209 ++++++++++++++++++++++
> >  hw/tpm/tpm_passthrough.c     | 409 ++++++++++++++++++++++++++++++
> +++++++++++--
> >  hw/tpm/tpm_tis.c            
| 151 +++++++++++++++-
> >  hw/tpm/tpm_tis.h            
|   2 +
> >  hw/tpm/tpm_util.c            |
223 +++++++++++++++++++++++
> >  hw/tpm/tpm_util.h            |
  7 +
> >  include/sysemu/tpm_backend.h |  12 ++
> >  qapi-schema.json            
|  18 +-
> >  qemu-options.hx            
 |  21 ++-
> >  qmp-commands.hx            
 |   2 +-
> >  tpm.c              
         |  11 +-
> >  13 files changed, 1056 insertions(+), 19 deletions(-)
> >  create mode 100644 hw/tpm/tpm_ioctl.h
> > 
> > -- 
> > 1.9.3
>