[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
Re: [Qemu-devel] [PATCH V13 5/7] Add a TPM Passthrough backend driver implementation
Mon, 12 Dec 2011 18:59:39 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) 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
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
providing the ability to access a TPM in a special state (e.g. after
This functionality is being used in the acTvSM Trusted Virtualization
which is available on .
+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.
- Re: [Qemu-devel] [PATCH V13 7/7] Add fd parameter for TPM passthrough driver, (continued)