From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Jerry Snitselaar <jsnitsel@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Laurent Bigonville <bigon@debian.org>,
Alexander.Steffen@infineon.com, linux-integrity@vger.kernel.org
Subject: Re: [tpmdd-devel] tpm device not showing up in /dev anymore
Date: Tue, 14 Nov 2017 16:59:53 +0200 [thread overview]
Message-ID: <20171114145953.m3a343qvgln2z4er@linux.intel.com> (raw)
In-Reply-To: <20171111203132.hkejjs6cdrrzq3y3@cantor>
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.
>
> > > With the old code I think it would have to wait either
> > > until the next time release_locality was called, or attempt to seize
> > > the tpm with the seize bit in the access register. I need to read
> > > through the spec some more, but does the tpm ever force a change when
> > > the request use bit is set, or does it leave it up to the software
> > > to deal with it and only gets involved in the case where the seize
> > > bit has been set?
> >
> > Do we handle these cases? Maybe something like that has happened..
> >
> > Jason
>
> If that is what happened in this case we should see the beenSeized bit
> set in the access register (assuming the chip is doing things properly),
> but it only had the tpmRegValidSts and tpmEstablishment bits set.
>
> There is code in the interrupt handling that notices if the locality
> changes if the chip has that capability, but I don't think there is
> anything that deals with the seize bit. Another thing to be looked
> at.
For me it is hard to understand who is the 3rd party who would be using
other locality and accessing TPM after OS handover in the regression in
question.
/Jarkko
next prev parent reply other threads:[~2017-11-14 14:59 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f9526f55-df96-64fc-a4d6-877ce04e7156@debian.org>
[not found] ` <dcad0104c46d4d5f88e642862bdb42c2@MUCSE603.infineon.com>
[not found] ` <47c4300b-8701-79a6-1c58-3a5853f4c5e3@debian.org>
[not found] ` <595efb25-8d87-f39d-037f-9c9a98462339@debian.org>
[not found] ` <857106e4bb864bb8a68b1381fffc8f50@MUCSE603.infineon.com>
[not found] ` <20170831164015.3ajgwydgxtippwoz@rhwork>
[not found] ` <0d9be244-ace0-030d-6ff9-c4e94c63b7e9@debian.org>
[not found] ` <20170906040555.fqedhmo5277sd6fq@linux.intel.com>
2017-10-14 8:13 ` [tpmdd-devel] tpm device not showing up in /dev anymore Jerry Snitselaar
2017-10-21 8:53 ` Laurent Bigonville
2017-10-23 13:23 ` Jarkko Sakkinen
2017-10-23 13:45 ` Jerry Snitselaar
2017-10-23 13:48 ` Laurent Bigonville
2017-10-24 13:51 ` Jarkko Sakkinen
2017-10-24 14:57 ` Jerry Snitselaar
2017-10-24 16:07 ` Jarkko Sakkinen
2017-11-09 0:04 ` Laurent Bigonville
2017-11-09 19:58 ` Laurent Bigonville
2017-11-09 23:50 ` Jerry Snitselaar
2017-11-10 2:19 ` Jerry Snitselaar
2017-11-10 0:28 ` Jerry Snitselaar
2017-11-10 7:07 ` Jerry Snitselaar
2017-11-10 8:21 ` Laurent Bigonville
2017-11-10 20:53 ` Jerry Snitselaar
2017-11-11 15:45 ` Jason Gunthorpe
2017-11-11 19:12 ` Jerry Snitselaar
2017-11-11 19:46 ` Jason Gunthorpe
2017-11-11 20:31 ` Jerry Snitselaar
2017-11-14 0:26 ` Laurent Bigonville
2017-11-14 2:45 ` Jason Gunthorpe
2017-11-14 14:59 ` Jarkko Sakkinen [this message]
2017-11-14 15:17 ` James Bottomley
2017-11-17 13:16 ` Jarkko Sakkinen
2018-01-02 23:54 ` Laurent Bigonville
2018-01-03 0:33 ` Jerry Snitselaar
2018-01-05 19:01 ` Laurent Bigonville
2018-02-09 10:53 ` Laurent Bigonville
2018-02-14 11:44 ` Jarkko Sakkinen
2018-03-09 17:24 ` Laurent Bigonville
2018-03-15 16:24 ` Jarkko Sakkinen
2018-05-03 11:38 ` Laurent Bigonville
2018-05-03 17:43 ` Jerry Snitselaar
2018-05-04 8:20 ` Jarkko Sakkinen
2018-05-04 8:18 ` Jarkko Sakkinen
2018-05-04 14:22 ` Jerry Snitselaar
2017-11-14 14:55 ` Jarkko Sakkinen
2017-11-14 14:43 ` Jarkko Sakkinen
2017-10-25 8:04 ` Laurent Bigonville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171114145953.m3a343qvgln2z4er@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=Alexander.Steffen@infineon.com \
--cc=bigon@debian.org \
--cc=jgg@ziepe.ca \
--cc=jsnitsel@redhat.com \
--cc=linux-integrity@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox