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
