From patchwork Wed Jan 3 00:33:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerry Snitselaar X-Patchwork-Id: 10141459 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 53F51601A1 for ; Wed, 3 Jan 2018 00:33:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 45E7628EC0 for ; Wed, 3 Jan 2018 00:33:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3A98928EC2; Wed, 3 Jan 2018 00:33:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D797928EC0 for ; Wed, 3 Jan 2018 00:33:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751039AbeACAd5 (ORCPT ); Tue, 2 Jan 2018 19:33:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44930 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750928AbeACAd5 (ORCPT ); Tue, 2 Jan 2018 19:33:57 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96674C049D5F; Wed, 3 Jan 2018 00:33:56 +0000 (UTC) Received: from localhost (ovpn-116-56.phx2.redhat.com [10.3.116.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2E8065D75C; Wed, 3 Jan 2018 00:33:56 +0000 (UTC) Date: Tue, 2 Jan 2018 17:33:55 -0700 From: Jerry Snitselaar To: Laurent Bigonville Cc: Jarkko Sakkinen , James Bottomley , Jason Gunthorpe , Alexander.Steffen@infineon.com, linux-integrity@vger.kernel.org Subject: Re: [tpmdd-devel] tpm device not showing up in /dev anymore Message-ID: <20180103003355.oaie7tych5lmtxiq@cantor> Reply-To: Jerry Snitselaar References: <9245ef7d-dd34-fa5f-6fd9-bfb9582f910e@debian.org> <20171110205300.eyfkoyabobv7llgb@localhost.localdomain> <20171111154516.GI17451@ziepe.ca> <20171111191257.owuqtgzie3ostsab@cantor> <20171111194647.GA6918@ziepe.ca> <20171111203132.hkejjs6cdrrzq3y3@cantor> <20171114145953.m3a343qvgln2z4er@linux.intel.com> <1510672631.4078.7.camel@HansenPartnership.com> <20171117131620.het4yxavz6lco6ow@linux.intel.com> <67ca8d8f-bd2c-a1ad-72d1-7f4b8df0a847@debian.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <67ca8d8f-bd2c-a1ad-72d1-7f4b8df0a847@debian.org> User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 03 Jan 2018 00:33:56 +0000 (UTC) Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed Jan 03 18, Laurent Bigonville wrote: >Le 17/11/17 à 14:16, Jarkko Sakkinen a écrit : >>On Tue, Nov 14, 2017 at 07:17:11AM -0800, James Bottomley wrote: >>>On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: >>>>On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: >>>>>On Sat Nov 11 17, Jason Gunthorpe wrote: >>>>>>On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: >>>>>> >>>>>>>Before the release_locality code would only actually release >>>>>>>the locality if the request use bit was set. So after it >>>>>>>grabbed the locality during probe it probably never released >>>>>>>it. The idea with the new code was to release it when it was no >>>>>>>longer needed so another requester would be able to take the >>>>>>>tpm without having to wait for it to be released. >>>>>>If I recall, this was so that system level things outside linux >>>>>>could access the TPM properly?? >>>>>> >>>>>Yes, that is what drove this initially. I believe Jarkko was also >>>>>thinking of the possibility in the future where something like a vm >>>>>could request a locality as well, but that is just a hazy >>>>>recollection of emails from back then. >>>>This was something I recall discussing in LPC 2016 in the hallway at >>>>least :-) A tidbit but it could make sense to tie it to VMM, not VM. >>>I think we should be extremely wary of different localities before we >>>have a cast iron definition of what they mean.  All the TPM PC spec >>>says is that locality 4 is reserved for firmware (meaning the kernel >>>should have no access) and it implies there's a privilege hierarchy, >>>making 4 the most privileged and 0 the least but leaves all the >>>definition to the OS.  Since we only have four other localities to play >>>with, we need a global definition of what they mean in Linux (and who >>>protects them) otherwise we'll get conflicting uses.  What does Windows >>>use them for? >>> >>>James >>No idea. If I had to guess, they use only one locality for OS as this >>what PTT/fTPM had when it didn't have localities. At least their >>implementation works with only one locality. >> > >No more idea then? :( Hi Laurent, Can you try the following debug patch (earlier idea of adding a sleep to allow tpm to complete state transition): --8<-- diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index fdde971bc810..6a9325b02059 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, int l) struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); + tpm_msleep(200); } static int request_locality(struct tpm_chip *chip, int l)