On Mon, Feb 20, 2012 at 03:25:37PM -0500, Stefan Berger wrote:
On 02/20/2012 02:51 PM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2011 at 08:43:20AM -0500, 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].
Usage example:
qemu-system-x86_64 -tpmdev passthrough,id=tpm0,path=/dev/tpm0 \
-device tpm-tis,tpmdev=tpm0 \
-cdrom test.iso -boot d
Some notes about the host TPM:
The TPM needs to be enabled and activated. If that's not the case one
has to go through the BIOS/UEFI and enable and activate that TPM for TPM
commands to work as expected.
It may be necessary to boot the kernel using tpm_tis.force=1 in the boot
command line or 'modprobe tpm_tis force=1' in case of using it as a module.
Regards,
Andreas Niederl, Stefan Berger
[1] http://trustedjava.sourceforge.net/
Signed-off-by: Andreas Niederl<address@hidden>
Signed-off-by: Stefan Berger<address@hidden>
So this was mentioned by Blue Swirl and Anthony and
I have to agree: it's not clear why this wants its own
thread.
This is not only due to how the Linux TPM driver works but also, as
previously mentioned, due to how I would like the libtpms driver to
work. The former does not support select() (yes, this is probably a
TPM driver problem but it has been around for ages and didn't matter
so far because only the TSS (TrouSerS) was meant to access the TPM).
The latter will certainly support creation of 2048 bit RSA keys and
disappear into e crypto function that also isn't select() able,
unless you end up introducing another thread here.
And you most
probably don't want the main thread to be busy for several seconds
(depending on availability of CPU cycles) to have that key created.
So in effect having this thread allows us to have a common
architecture for both passthrough and libtpms backends.
OK, so let's say this is a work around linux tpm
backend limitations. But it is unfortunate that this
spills into frontend code.
How about taking the global qemu lock instead?
Also, you need to be more careful with
running your thread, e.g. it must be stopped on
vmstop, etc. It is probably a good idea to use
a genetic thread pool with all that logic.