|
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 theemulated 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 TrustedBoot).This functionality is being used in the acTvSM Trusted Virtualization Platformwhich 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
[Prev in Thread] | Current Thread | [Next in Thread] |