Re: Kernel 5.0 regression in /dev/tpm0 access

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2019-03-09 at 22:48 +0200, Mantas Mikulėnas wrote:
> Hello, I'm not entirely sure where I'm supposed to send this –
> 
> As of kernel 5.0.0, I'm unable to use the TPM on my laptop (HP
> EliteBook 840 G4, with Infineon TPM 2.0) with the current version of
> Intel TPM2 tools (tpm2-tss 2.2.0, tpm2-tools 3.1.3). The tools – e.g.
> tpm2_pcrlist or tpm2_nvread – sometimes succeed, sometimes are unable
> to read anything from /dev/tpm0 at all (immediately report an EOF),
> and sometimes are able to read part of the response but stop halfway.

Just as a data point, I don't see this on 5.0 with my setup.  However,
unlike you I'm using the ibmtss which makes direct connections to
/dev/tpmrm0 so our two situations definitely aren't equivalent.

> The problem seems to be caused by commit 9488585b21bef0df12 ("tpm:
> add support for partial reads"); I've compiled 5.0.0 with that commit
> reverted and the tpm2 tools no longer have problems. Investigating
> with `strace` shows that the tools frequently get 0 bytes out of a 4k
> read:
> 
> [good]
> write(3,
> "\200\1\0\0\0\32\0\0\1~\0\0\0\2\0\4\3\0\0\0\0\v\3\0\377\377", 26) =
> 26
> poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3,
> revents=POLLIN}])
> read(3,
> "\200\1\0\0\0012\0\0\0\0\0\0\0h\0\0\0\2\0\4\3\0\0\0\0\v\3\0\377\0\0\0
> "...,
> 4096) = 306
> 
> [bad]
> write(3, "\200\1\0\0\0\32\0\0\1~\0\0\0\2\0\4\3\0\0\0\0\v\3\0\0\377",
> 26) = 26
> poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3,
> revents=POLLIN}])
> read(3, "", 4096)                       = 0
> write(2, "WARNING:tcti:src/tss2-tcti/tcti-"..., 97) = 97
> write(2, "ERROR: ", 7)                  = 7
> write(2, "read pcr failed. tpm error 0xa00"..., 34) = 34
> 
> (Interestingly, this is very difficult to reproduce under strace, yet
> almost guaranteed to happen when not being traced. It almost feels as
> if this is a timing issue?)

There is a significant difference in the way our applications are
working.  for instance if I strace

tssgetcapability -cap 0

I see this (cutting out everything before the TPM open and after the
TPM close)

openat(AT_FDCWD, "/dev/tpmrm0", O_RDWR) = 3
write(3,
"\200\1\0\0\0\26\0\0\1z\0\0\0\0\0\0\0\0\0\0\0@", 22) = 22
read(3,
"\200\1\0\0\0\235\0\0\0\0\0\0\0\0\0\0\0\0\27\0\1\0\0\0\t\0\4\0\0\0\4\0"
..., 4096) = 157
close(3)

So we do a simple write command and read the return (which simply hangs
until the TPM is ready with the data).  We don't poll like your
application does above, so it seems obvious that the break must be in
the polling code.

James