[Top][All Lists]

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

Re: [Qemu-devel] [PATCH V8 07/14] Implementation of the libtpms-based ba

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH V8 07/14] Implementation of the libtpms-based backend
Date: Thu, 01 Sep 2011 21:24:26 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 09/01/2011 01:27 PM, Michael S. Tsirkin wrote:
On Wed, Aug 31, 2011 at 10:35:58AM -0400, Stefan Berger wrote:
This patch provides the glue for the TPM TIS interface (frontend) to
the libtpms that provides the actual TPM functionality.

Some details:

This part of the patch provides support for the spawning of a thread
that will interact with the libtpms-based TPM. It expects a signal
from the frontend to wake and pick up the TPM command that is supposed
to be processed and delivers the response packet using a callback
function provided by the frontend.

The backend connects itself to the frontend by filling out an interface
structure with pointers to the function implementing support for various

In this part a structure with callback functions is registered with
libtpms. Those callback functions are invoked by libtpms for example to
store the TPM's state.

The libtpms-based backend implements functionality to write into a
Qemu block storage device rather than to plain files. With that we
can support VM snapshotting and we also get the possibility to use
encrypted QCoW2 for free. Thanks to Anthony for pointing this out.
The storage part of the driver has been split off into its own patch.

   - cache a copy of the last permanent state blob
   - move some functions into tpm_builtin.h
   - reworked parts of the error path handling where the TPM is
     now used to process commands under error conditions and the callbacks
     make the TPM aware of the error conditions. Only as the last resort
     fault messages are sent by the backend driver circumventing the TPM.
   - add out_len variable used in the thread

   - check access() to TPM's state file and report error if file is not

   - temporarily deactivate the building of the tpm_builtin.c until
     subsequent patch completely converts it to the libtpms based driver

   - fixes to adhere to the qemu coding style

Signed-off-by: Stefan Berger<address@hidden>

  configure        |    1
  hw/tpm_builtin.c |  450 
  hw/tpm_builtin.h |   56 ++++++
  3 files changed, 482 insertions(+), 25 deletions(-)

Index: qemu-git/hw/tpm_builtin.c
--- qemu-git.orig/hw/tpm_builtin.c
+++ qemu-git/hw/tpm_builtin.c
@@ -1,5 +1,5 @@
- *  builtin 'null' TPM driver
+ *  builtin TPM driver based on libtpms
Just wondering - might a stub driver be useful for
basic testing on systems without TPM hardware?
'systems without TPM hardware' -- we're not relying on underlying TPM provided by the host. But I assume that's not what you meant.

A 'null' driver, which responds to every command with an error response, is added in patch 13.

The namespace comment applies to this and all other patches.

In patch 6 I am adding a skeleton backend driver that I am transforming into the libtpms-based backend in patch 7. I didn't name the file tpm_skeleton.c but already tpm_builtin.c and all functions already start with the prefix tpm_builtin. This presumably makes it easier to review since the 'meat' is added in part 7 and unnecessary function name changes are avoided. The null driver later on and the passthrough driver (posted by Andreas Niederl) all can be derived rather easily from that initial skeleton driver. In those we do adhere to the namespace requirement.


reply via email to

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