From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rze8d-0007Fe-Em for qemu-devel@nongnu.org; Mon, 20 Feb 2012 20:03:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rze8b-0002nf-I6 for qemu-devel@nongnu.org; Mon, 20 Feb 2012 20:03:27 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:53301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rze8b-0002nX-2C for qemu-devel@nongnu.org; Mon, 20 Feb 2012 20:03:25 -0500 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Feb 2012 18:03:24 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id C9039C90050 for ; Mon, 20 Feb 2012 20:03:20 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1L13KS9348672 for ; Mon, 20 Feb 2012 20:03:20 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1L13J73009521 for ; Mon, 20 Feb 2012 23:03:20 -0200 Message-ID: <4F42ED57.3000107@linux.vnet.ibm.com> Date: Mon, 20 Feb 2012 20:03:19 -0500 From: Stefan Berger 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> In-Reply-To: <20120220211530.GB19278@redhat.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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, andreas.niederl@iaik.tugraz.at 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 ? 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