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

["Michael S. Tsirkin" <mst@redhat.com>]

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.


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

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