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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

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<andreas.niederl@iaik.tugraz.at>
>> Signed-off-by: Stefan Berger<stefanb@linux.vnet.ibm.com>
> 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.


> I would go further and claim that forcing a threaded build for a
> periferal just looks wrong. What's going on, select+unblocking access
> does not work for tpm?

Yep.

> If this behaves like  a normal device
> we won't need locking ...
>

Stefan