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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/20/2012 07:03 PM, Stefan Berger wrote:
> 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 ?

The model for handling this in QEMU is to use a thread pool.  We do this for 
AIO, virtio-9p, VNC, etc.

What's run in the thread pool is typically minimal (a single system call) but in 
the case of the libtpms backend, may be a full library call to the libtpms 
driver.  The key point is that we're not mixing re-entrant code (the code that 
interfaces with libtpms) with non re-entrant code (QEMU).

Submitting to the thread pool and processing the response is all done via the 
thread pool.

Regards,

Anthony Liguori

>
> 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
>
>