Le 03/01/18 à 01:33, Jerry Snitselaar a écrit :
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)
Thanks,
With that patch the device is showing up again in /dev and I
tpm_sealdata is working as well
