Tools no longer work against hardware TPM device on e.g. Intel NUC's tpm_crb driver on recent kernels

[Antti S. Lankila]

Executing something like this should cause the TPM to return 4 bytes of random data:

$ sudo strace tpm2_getrandom -T device 4

strace shows that this happens instead:

openat(AT_FDCWD, "/dev/tpm0", O_RDWR) = 3
write(3, "\200\1\0\0\0\f\0\0\1{\0\4", 12) = 12
read(3, "\200\1\0\0\0\f\0\0\1{\0\4", 4096) = 12

e.g. writing a command to TPM seems to cause it to just echo the written command back, rather than the TPM's actual response for this command. This is not how it used to work in 16.04. This behavior is not expected by the tools, which parse this as a TPM error:

ERROR: TPM2_GetRandom Error. TPM Error:0x17b

However, we haven't seen the response yet, so we can't determine if TPM had an error processing the command. It's just a broken assumption made by the TPM interface library that the read() after command gives the response's data rather than the request's data. All other TPM commands fail similarly for this reason. (For what it's worth, there identical problem with the tss2 package, which provides an alternative suite of TPM 2.0 related tools.)

This used to work on the 4.10 kernel from 16.04. It was already broken on the Hardware Enablement 16.04 kernel that's based on 4.13, so there must have been some change in kernel that has broken this between 4.11 to 4.13 releases. I was deferring writing this bug until I managed to test it on 4.15, but alas, the tools don't work there either.

The big change in kernel seems to be that a TPM in-kernel resource manager has been added. The resource manager's point is to allow multiple processes to use TPM concurrently. It is unclear to me whether this also implies changes to the way the tpm0 device should work. I am in fact having really hard time finding any documentation of the tpm0 interface, so I can't even confirm if this programming API's apparent change has been intended or not. I am currently assuming that kernel is working properly and it's the tools that must be updated to resolve the problem, but it is also possible that this bug should be opened against the kernel itself instead. It is conceivable that the issue is limited to subset of TPM drivers. Unfortunately, the only hardware with TPM I have available is based on tpm_crb driver on an Intel NUC, so I can't test if the tools would work on some other hardware implementation.

Regarding the resource manager, trying the commands against the resource-managed TPM device makes no difference in the result:

$ sudo strace tpm2_getrandom -T device -d /dev/tpmrm0 4
...
openat(AT_FDCWD, "/dev/tpmrm0", O_RDWR) = 3
write(3, "\200\1\0\0\0\f\0\0\1{\0\4", 12) = 12
read(3, "\200\1\0\0\0\f\0\0\1{\0\4", 4096) = 12

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: tpm2-tools 2.1.0-1build1
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
ApportVersion: 2.20.9-0ubuntu4
Architecture: amd64
Date: Sun Apr 8 07:24:12 2018
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: tpm2-tools
UpgradeStatus: No upgrade log present (probably fresh install)

[Antti S. Lankila (alankila)]

I'm adding a comment here as I have new information. I discovered a tpm_crb-driven tpm implementation on a laptop running Bionic (ASUS ZenBook UX360CAK). Now that I happened to test tpm2-tools on it, I discovered that:

- tpm2_getrandom worked on it,
- tpm2_listpcrs also worked.

The /dev/tpm0 device behaves as it used to, e.g. writing a command request sends back a response, not an echo of the request. Therefore, I am making the following conclusions:

- tpm2-tools itself is fine,
- tpm_crb driver per se is probably fine, though there likely is a bug in linux kernel somewhere,
- /dev/tpm0 is still programmed the same way, by writing requests and reading responses.

The target hardware where things still don't work is an Intel NUC 6CAYB.