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 04:15 PM, Michael S. Tsirkin wrote:
> 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<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.
>>
> 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.

Some backends may be able to react to a pthread_kill() 
(qemu_thread_kill() ?) which should be able to deliver a SIG_TERM to a 
thread. The passthrough thread, however, is not going to be able to 
react to this if it is stuck in the write() call to /dev/tpm0. I am 
sending the passthrough backend a signal to terminate and then do a 
qemu_thread_join() to wait for it to end. The libtpms backend on the 
other hand may be able to support a pthread_kill().
Why would I need a thread pool ?

    Stefan



>
>>> 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.
> Then maybe it's better to make tpm *depend* on threads,
> not force them.

And how would that change the code ?


    Stefan