Public bug reported:

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
 PATH=(custom, no user)
SourcePackage: tpm2-tools
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: tpm2-tools (Ubuntu)
     Importance: Undecided
         Status: New

** Tags: amd64 apport-bug bionic

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

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

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to