qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V13 5/7] Add a TPM Passthrough backend driver im


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH V13 5/7] Add a TPM Passthrough backend driver implementation
Date: Mon, 12 Dec 2011 18:59:39 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.15

On 12/12/2011 06:27 PM, Anthony Liguori wrote:
On 12/12/2011 01:12 PM, Stefan Berger wrote:
From Andreas Niederl's original posting with adaptations where necessary:

This patch is based of off version 9 of Stefan Berger's patch series
   "Qemu Trusted Platform Module (TPM) integration"
and adds a new backend driver for it.

This patch adds a passthrough backend driver for passing commands sent to the
emulated TPM device directly to a TPM device opened on the host machine.

Thus it is possible to use a hardware TPM device in a system running on QEMU, providing the ability to access a TPM in a special state (e.g. after a Trusted
Boot).

This functionality is being used in the acTvSM Trusted Virtualization Platform
which is available on [1].
[...]

+static void *tpm_passthrough_main_loop(void *d)
+{
+    TPMPassthruThreadParams *thr_parms = d;
+    TPMPassthruState *tpm_pt = thr_parms->tb->s.tpm_pt;
+    uint32_t in_len, out_len;
+    uint8_t *in, *out;
+    uint8_t locty;
+    TPMLocality *cmd_locty;
+    int ret;

This is rather scary. I'd rather see us make use of a GThreadPool in order to submit read/write requests asynchronously to the /dev/tpm device. I don't think the code should be structured expecting synchronous command execution.

This part here is running as a thread, create via qemu_thread_create(). Relative to the main thread this is of course running asynchronously. The same design will re-appear when the libtpms based TPM backend appears. Here we will need a thread for concurrent execution of more time consuming crypto functions.

Regards,
   Stefan




reply via email to

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