qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v4 0/4] Extend TPM support with a QEMU-external TPM
Date: Tue, 23 Jun 2015 08:07:16 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]