From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAUwH-0003wz-KO for qemu-devel@nongnu.org; Wed, 21 Mar 2012 19:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAUwE-0007KV-Eh for qemu-devel@nongnu.org; Wed, 21 Mar 2012 19:27:33 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAUwE-0007KB-8f for qemu-devel@nongnu.org; Wed, 21 Mar 2012 19:27:30 -0400 Received: by obbwd20 with SMTP id wd20so1159713obb.4 for ; Wed, 21 Mar 2012 16:27:28 -0700 (PDT) Message-ID: <4F6A63DC.5000508@codemonkey.ws> Date: Wed, 21 Mar 2012 18:27:24 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1323870202-25742-1-git-send-email-stefanb@linux.vnet.ibm.com> <1323870202-25742-6-git-send-email-stefanb@linux.vnet.ibm.com> <20120220195104.GA18751@redhat.com> <4F42AC41.8090304@linux.vnet.ibm.com> <20120220211530.GB19278@redhat.com> <4F42ED57.3000107@linux.vnet.ibm.com> In-Reply-To: <4F42ED57.3000107@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V14 5/7] Add a TPM Passthrough backend driver implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: andreas.niederl@iaik.tugraz.at, qemu-devel@nongnu.org, "Michael S. Tsirkin" 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 >>>>> Signed-off-by: Stefan Berger >>>> 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 > >