tpm_tis TPM2.0 not detected on cold boot

tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

Hi again,

after my UEFI firmware mod/hack to flash the newest available Nuvoton firmware
to the NCPT650 the selftest error went away. Since then the TPM worked without
any further problems, at least after warm reboots.

What I didn't notice before is that it does NOT work after a cold (re)boot.
There is no difference between Intel Firmware TPM and the Nuvoton TPM.
I can reproduce the error for both. I did not test TPM1.2 again.

dmesg warm (re)boot:
--------------------
> dmesg | grep -i tpm
[    0.000000] efi:  ACPI
2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bc018 
[    0.003368] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
S06   00001260 AMI  00000000)
[    3.610138] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)


dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1:
----------------------------------------------------------
> dmesg | grep -i tpm
[    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
break=premount tpm_tis.interrupts=0 tpm_tis.force=1
[    0.000000] efi:  ACPI
2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bb018 
[    0.003531] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
S06   00001260 AMI  00000000)
[    0.162005] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8
break=premount tpm_tis.interrupts=0 tpm_tis.force=1
[    3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)
[    3.683117] tpm_tis tpm_tis: can't request region for resource [mem
0xfed40000-0xfed44fff]
[    3.691378] tpm_tis: probe of tpm_tis failed with error -16
[    4.572539] ima: Error Communicating to TPM chip


dmesg cold boot:
----------------
> dmesg | grep -i tpm
[    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
break=premount
[    0.000000] efi:  ACPI
2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
3.0=0x9ebea000  MEMATTR=0x98fb2298  TPMEventLog=0x972bb018 
[    0.003559] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
S06   00001260 AMI  00000000)
[    0.161958] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8
break=premount
[    5.245801] ima: No TPM chip found, activating TPM-bypass!


Any ideas how to debug this?

Thanks
Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

Hi all,

On Sun, 2018-12-16 at 14:32 +0100, Michael Niewöhner wrote:
> Hi again,
> 
> after my UEFI firmware mod/hack to flash the newest available Nuvoton firmware
> to the NCPT650 the selftest error went away. Since then the TPM worked without
> any further problems, at least after warm reboots.
> 
> What I didn't notice before is that it does NOT work after a cold (re)boot.
> There is no difference between Intel Firmware TPM and the Nuvoton TPM.
> I can reproduce the error for both. I did not test TPM1.2 again.
> 
> dmesg warm (re)boot:
> --------------------
> > dmesg | grep -i tpm
> 
> [    0.000000] efi:  ACPI
> 2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
> 3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bc018 
> [    0.003368] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
> S06   00001260 AMI  00000000)
> [    3.610138] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)
> 
> 
> dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1:
> ----------------------------------------------------------
> > dmesg | grep -i tpm
> 
> [    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> [    0.000000] efi:  ACPI
> 2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
> 3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bb018 
> [    0.003531] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
> S06   00001260 AMI  00000000)
> [    0.162005] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> [    3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)
> [    3.683117] tpm_tis tpm_tis: can't request region for resource [mem
> 0xfed40000-0xfed44fff]
> [    3.691378] tpm_tis: probe of tpm_tis failed with error -16
> [    4.572539] ima: Error Communicating to TPM chip
> 
> 
> dmesg cold boot:
> ----------------
> > dmesg | grep -i tpm
> 
> [    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount
> [    0.000000] efi:  ACPI
> 2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
> 3.0=0x9ebea000  MEMATTR=0x98fb2298  TPMEventLog=0x972bb018 
> [    0.003559] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
> S06   00001260 AMI  00000000)
> [    0.161958] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount
> [    5.245801] ima: No TPM chip found, activating TPM-bypass!
> 
> 
> Any ideas how to debug this?
> 
> Thanks
> Michael


I have been doing some more debugging - as far as I were able to. These are my
results:

Doing a cold boot I was getting "No TPM chip found" in most cases. I found out
that the TPM will not be found if the bootloader (systemd-boot in my case) has a
timeout value of 10 seconds. This was set for some other tests...

When I remove the timeout and boot directly to the linux kernel, I get that
"2314 TPM-self test error" since it has not finished, yet. The TPM is detected
by IMA and works fine then.

Some more tests showed that any delay before booting the kernel causes the TPM
to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some very
rare cases the TPM got detected.

I wanted to know if the TPM is in an well initialized state at the time of that
error. Since I was not able to get some test/debug kernel patches working I
decided to try kexec. It turned out that the TPM is indeed correctly working and
will be detected just fine by linux after kexec!

Is there anyone having an idea what could be wrong here? I am willing to debug
this but I have really no idea where to start :-(

Best regards
Michael

----

kexec test output:

<...>
(initramfs) dmesg | grep -i tpm
[    0.000000] Command line: initrd=\initrd console=ttyS0,115200n8
root=zfs:rpool/ROOT tpm.override_rng_quality=1024 quiet break=top
[    0.000000] efi:  ACPI
2.0=0x9ea7e000  ACPI=0x9ea7e000  SMBIOS=0x9f5eb000  SMBIOS
3.0=0x9f5ea000  MPS=0xfca00  ESRT=0x9c07b118  MEMATTR=0x9982d018  TPMEventLog=0x
98ace018 
[    0.001310] ACPI: TPM2 0x000000009EAB7F70 000034 (v03 LENOVO TC-
S06   00001260 AMI  00000000)
[    0.159568] Kernel command line: initrd=\initrd console=ttyS0,115200n8
root=zfs:rpool/ROOT quiet break=top
[    1.376200] ima: No TPM chip found, activating TPM-bypass!

/ # kexec -f --initrd=/initrd.img-4.19.9\+ --reuse-cmdline /vmlinuz-4.19.9\+
[  890.632541] kexec_core: Starting new kernel
<...>
(initramfs) dmesg | grep -i tpm
[    0.000000] Command line: initrd=\initrd console=ttyS0,115200n8
root=zfs:rpool/ROOT tpm.override_rng_quality=1024 quiet break=top
[    0.000000] efi:  ACPI
2.0=0x9ea7e000  ACPI=0x9ea7e000  SMBIOS=0x9f5eb000  SMBIOS
3.0=0x9f5ea000  MPS=0xfca00  ESRT=0x9c07b118  MEMATTR=0x9982d018  TPMEventLog=0x
98ace018 
[    0.001272] ACPI: TPM2 0x000000009EAB7F70 000034 (v03 LENOVO TC-
S06   00001260 AMI  00000000)
[    0.168244] Kernel command line: initrd=\initrd console=ttyS0,115200n8
root=zfs:rpool/ROOT quiet break=top
[    0.632922] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)

Re: tpm_tis TPM2.0 not detected on cold boot

[Mimi Zohar]

On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:

> When I remove the timeout and boot directly to the linux kernel, I get that
> "2314 TPM-self test error" since it has not finished, yet. The TPM is detected
> by IMA and works fine then.
> 
> Some more tests showed that any delay before booting the kernel causes the TPM
> to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some very
> rare cases the TPM got detected.
> 
> I wanted to know if the TPM is in an well initialized state at the time of that
> error. Since I was not able to get some test/debug kernel patches working I
> decided to try kexec. It turned out that the TPM is indeed correctly working and
> will be detected just fine by linux after kexec!

No surprise here.  kexec would be the equivalent of a soft reboot.

> 
> Is there anyone having an idea what could be wrong here? I am willing to debug
> this but I have really no idea where to start :-(

A while ago, I was "playing" with a pi.  Commenting out
tpm2_do_selftest() seemed to resolve a similar problem, but that was
before James' patches.  I don't know if that would make a difference
now.

Mimi

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

Hi Mimi,

On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> 
> > When I remove the timeout and boot directly to the linux kernel, I get that
> > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > detected
> > by IMA and works fine then.
> > 
> > Some more tests showed that any delay before booting the kernel causes the
> > TPM
> > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some
> > very
> > rare cases the TPM got detected.
> > 
> > I wanted to know if the TPM is in an well initialized state at the time of
> > that
> > error. Since I was not able to get some test/debug kernel patches working I
> > decided to try kexec. It turned out that the TPM is indeed correctly working
> > and
> > will be detected just fine by linux after kexec!
> 
> No surprise here.  kexec would be the equivalent of a soft reboot.

Well, I am not that deep in kexec internals but isn't a soft reboot much more
than a kexec? I thought kexec would "just" load the new kernel to memory and
executes it while a soft reboot goes at least through some UEFI initialization.
For example, my pwm fans - in fact the EC - get resetted on a soft reboot, while
a kexec does not touch them.

That is why I wanted to test if there is a different behaviour on kexec compared
to a "real" soft reboot. If there was such difference I would have assumed a
UEFI bug that does not initialize the TPM correctly.
Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in the
same state as before kexec and since there is no difference between sr and kexec
I have the feeling there is something wrong in the kernel.

Correct me if I am wrong here, please.

My current workaround is to do a machine_emergency_reboot() when TPM isn't
detected correctly. That is a pretty hard workaround but it seems to work for
now...

> 
> > 
> > Is there anyone having an idea what could be wrong here? I am willing to
> > debug
> > this but I have really no idea where to start :-(
> 
> A while ago, I was "playing" with a pi.  Commenting out
> tpm2_do_selftest() seemed to resolve a similar problem, but that was
> before James' patches.  I don't know if that would make a difference
> now.

Hm, I will try that..


> Mimi
> 

There is another issue but I don't know if both are related. Maybe that's just a
timing issue...

root@debian:~# dd if=/dev/hwrng bs=1 count=1
dd: error reading '/dev/hwrng': Operation not permitted
0+0 records in
0+0 records out
0 bytes copied, 0.755958 s, 0.0 kB/s
root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
count=1 | xxd
dd: error reading '/dev/hwrng': Operation not permitted
0+0 records in
0+0 records out
0 bytes copied, 0.755697 s, 0.0 kB/s
1+0 records in
1+0 records out
00000000: 52                                       R
1 byte copied, 0.0106268 s, 0.1 kB/s


Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote:
> Hi Mimi,
> 
> On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> > 
> > > When I remove the timeout and boot directly to the linux kernel, I get
> > > that
> > > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > > detected
> > > by IMA and works fine then.
> > > 
> > > Some more tests showed that any delay before booting the kernel causes the
> > > TPM
> > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some
> > > very
> > > rare cases the TPM got detected.
> > > 
> > > I wanted to know if the TPM is in an well initialized state at the time of
> > > that
> > > error. Since I was not able to get some test/debug kernel patches working
> > > I
> > > decided to try kexec. It turned out that the TPM is indeed correctly
> > > working
> > > and
> > > will be detected just fine by linux after kexec!
> > 
> > No surprise here.  kexec would be the equivalent of a soft reboot.
> 
> Well, I am not that deep in kexec internals but isn't a soft reboot much more
> than a kexec? I thought kexec would "just" load the new kernel to memory and
> executes it while a soft reboot goes at least through some UEFI
> initialization.
> For example, my pwm fans - in fact the EC - get resetted on a soft reboot,
> while
> a kexec does not touch them.
> 
> That is why I wanted to test if there is a different behaviour on kexec
> compared
> to a "real" soft reboot. If there was such difference I would have assumed a
> UEFI bug that does not initialize the TPM correctly.
> Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in
> the
> same state as before kexec and since there is no difference between sr and
> kexec
> I have the feeling there is something wrong in the kernel.
> 
> Correct me if I am wrong here, please.
> 
> My current workaround is to do a machine_emergency_reboot() when TPM isn't
> detected correctly. That is a pretty hard workaround but it seems to work for
> now...
> 
> > 
> > > 
> > > Is there anyone having an idea what could be wrong here? I am willing to
> > > debug
> > > this but I have really no idea where to start :-(
> > 
> > A while ago, I was "playing" with a pi.  Commenting out
> > tpm2_do_selftest() seemed to resolve a similar problem, but that was
> > before James' patches.  I don't know if that would make a difference
> > now.
> 
> Hm, I will try that..
> 

Unfortunately this did not change anything

> 
> > Mimi
> > 
> 
> There is another issue but I don't know if both are related. Maybe that's just
> a
> timing issue...
> 
> root@debian:~# dd if=/dev/hwrng bs=1 count=1
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755958 s, 0.0 kB/s
> root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
> count=1 | xxd
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755697 s, 0.0 kB/s
> 1+0 records in
> 1+0 records out
> 00000000: 52                                       R
> 1 byte copied, 0.0106268 s, 0.1 kB/s
> 
> 
> Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Mimi Zohar]

On Tue, 2018-12-25 at 14:55 +0100, Michael Niewöhner wrote:
> On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote:
> > Hi Mimi,
> > 
> > On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> > > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> > > 
> > > > When I remove the timeout and boot directly to the linux kernel, I get
> > > > that
> > > > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > > > detected
> > > > by IMA and works fine then.
> > > > 
> > > > Some more tests showed that any delay before booting the kernel causes the
> > > > TPM
> > > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some
> > > > very
> > > > rare cases the TPM got detected.
> > > > 
> > > > I wanted to know if the TPM is in an well initialized state at the time of
> > > > that
> > > > error. Since I was not able to get some test/debug kernel patches working
> > > > I
> > > > decided to try kexec. It turned out that the TPM is indeed correctly
> > > > working
> > > > and
> > > > will be detected just fine by linux after kexec!
> > > 
> > > No surprise here.  kexec would be the equivalent of a soft reboot.
> > 
> > Well, I am not that deep in kexec internals but isn't a soft reboot much more
> > than a kexec? I thought kexec would "just" load the new kernel to memory and
> > executes it while a soft reboot goes at least through some UEFI
> > initialization.
> > For example, my pwm fans - in fact the EC - get resetted on a soft reboot,
> > while
> > a kexec does not touch them.
> > 

Similarly, the PCRs are not reset on kexec.

> > That is why I wanted to test if there is a different behaviour on kexec
> > compared
> > to a "real" soft reboot. If there was such difference I would have assumed a
> > UEFI bug that does not initialize the TPM correctly.
> > Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in
> > the
> > same state as before kexec and since there is no difference between sr and
> > kexec
> > I have the feeling there is something wrong in the kernel.
> > 
> > Correct me if I am wrong here, please.

But the problem you've described is on a cold boot, not a soft reboot.
 Both the soft reboot and kexec are working properly.  It seems the
difference is that on a cold boot, the TPM takes longer to initialize.

> > My current workaround is to do a machine_emergency_reboot() when TPM isn't
> > detected correctly. That is a pretty hard workaround but it seems to work for
> > now...

This is a again soft reboot.

>  
> > > 
> > > > 
> > > > Is there anyone having an idea what could be wrong here? I am willing to
> > > > debug
> > > > this but I have really no idea where to start :-(
> > > 
> > > A while ago, I was "playing" with a pi.  Commenting out
> > > tpm2_do_selftest() seemed to resolve a similar problem, but that was
> > > before James' patches.  I don't know if that would make a difference
> > > now.
> > 
> > Hm, I will try that..
> > 
> 
> Unfortunately this did not change anything

Not much I can do now.  After vacation, I'll set up the pi to see if
it is working properly with a recent kernel.

Mimi

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Sat, 2018-12-29 at 22:33 -0500, Mimi Zohar wrote:
> On Tue, 2018-12-25 at 14:55 +0100, Michael Niewöhner wrote:
> > On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote:
> > > Hi Mimi,
> > > 
> > > On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> > > > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> > > > 
> > > > > When I remove the timeout and boot directly to the linux kernel, I get
> > > > > that
> > > > > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > > > > detected
> > > > > by IMA and works fine then.
> > > > > 
> > > > > Some more tests showed that any delay before booting the kernel causes
> > > > > the
> > > > > TPM
> > > > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in
> > > > > some
> > > > > very
> > > > > rare cases the TPM got detected.
> > > > > 
> > > > > I wanted to know if the TPM is in an well initialized state at the
> > > > > time of
> > > > > that
> > > > > error. Since I was not able to get some test/debug kernel patches
> > > > > working
> > > > > I
> > > > > decided to try kexec. It turned out that the TPM is indeed correctly
> > > > > working
> > > > > and
> > > > > will be detected just fine by linux after kexec!
> > > > 
> > > > No surprise here.  kexec would be the equivalent of a soft reboot.
> > > 
> > > Well, I am not that deep in kexec internals but isn't a soft reboot much
> > > more
> > > than a kexec? I thought kexec would "just" load the new kernel to memory
> > > and
> > > executes it while a soft reboot goes at least through some UEFI
> > > initialization.
> > > For example, my pwm fans - in fact the EC - get resetted on a soft reboot,
> > > while
> > > a kexec does not touch them.
> > > 
> 
> Similarly, the PCRs are not reset on kexec.
> 
> > > That is why I wanted to test if there is a different behaviour on kexec
> > > compared
> > > to a "real" soft reboot. If there was such difference I would have assumed
> > > a
> > > UEFI bug that does not initialize the TPM correctly.
> > > Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be
> > > in
> > > the
> > > same state as before kexec and since there is no difference between sr and
> > > kexec
> > > I have the feeling there is something wrong in the kernel.
> > > 
> > > Correct me if I am wrong here, please.
> 
> But the problem you've described is on a cold boot, not a soft reboot.
>  Both the soft reboot and kexec are working properly.  It seems the

Exactly, soft reboot / warm boot works.
What I don't understand is WHY it works. If it was a hardware problem I would
expect it not to work after it previously failed after a cold boot but that is
not the case. The warm reboot / kexec does reinitialize anything.
That means maybe it would be sufficient to reinitialize that - whatever it is -
to get the TPM working instead of needing a full warm reboot.

> difference is that on a cold boot, the TPM takes longer to initialize.

Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does
not solve the problem. So the problem is NOT that the TPM takes longer to
initialize. Even adding a delay of 20 seconds before TPM init does not solve
that while that should be more than enough time.

> 
> > > My current workaround is to do a machine_emergency_reboot() when TPM isn't
> > > detected correctly. That is a pretty hard workaround but it seems to work
> > > for
> > > now...
> 
> This is a again soft reboot.
> 
> >  
> > > > > Is there anyone having an idea what could be wrong here? I am willing
> > > > > to
> > > > > debug
> > > > > this but I have really no idea where to start :-(
> > > > 
> > > > A while ago, I was "playing" with a pi.  Commenting out
> > > > tpm2_do_selftest() seemed to resolve a similar problem, but that was
> > > > before James' patches.  I don't know if that would make a difference
> > > > now.
> > > 
> > > Hm, I will try that..
> > > 
> > 
> > Unfortunately this did not change anything
> 
> Not much I can do now.  After vacation, I'll set up the pi to see if
> it is working properly with a recent kernel.
> 
> Mimi
> 

Re: tpm_tis TPM2.0 not detected on cold boot

[Ken Goldman]

On 12/30/2018 8:22 AM, Michael Niewöhner wrote:
>> difference is that on a cold boot, the TPM takes longer to initialize.
> Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does
> not solve the problem. So the problem is NOT that the TPM takes longer to
> initialize. Even adding a delay of 20 seconds before TPM init does not solve
> that while that should be more than enough time.
> 

This may be TPM hardware dependent.  As I understand it ...

A TPM is permitted to run it's self tests in the background after an
Init (cold boot) , but it's not required to do so.

A TPM that does not - that waits until one of the self test commands is 
issued - will appear to take longer to initialize.

In fact, it's not taking longer.  It's just waiting for some software
to issue a self test command, and will wait forever.

Re: tpm_tis TPM2.0 not detected on cold boot

[Mimi Zohar]

On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote:

> > difference is that on a cold boot, the TPM takes longer to initialize.
> 
> Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does
> not solve the problem. So the problem is NOT that the TPM takes longer to
> initialize. Even adding a delay of 20 seconds before TPM init does not solve
> that while that should be more than enough time.

The purpose of commenting out the TPM2 selftest was to minimize the
TPM initialization delay, so that the TPM is ready before IMA.  After
James' patch that wasn't needed anymore.

Looking back at this thread, I see you're using systemd-boot, not
grub2.  When you commented out the systemd-boot timeout, IMA found the
TPM.  The question is why isn't the TPM ready with the timeout before
IMA (like above)?  Has systemd-boot done the selftest?

Mimi

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Mon, 2018-12-31 at 16:17 -0500, Mimi Zohar wrote:
> On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote:
> 
> > > difference is that on a cold boot, the TPM takes longer to initialize.
> > 
> > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager
> > does
> > not solve the problem. So the problem is NOT that the TPM takes longer to
> > initialize. Even adding a delay of 20 seconds before TPM init does not solve
> > that while that should be more than enough time.
> 
> The purpose of commenting out the TPM2 selftest was to minimize the
> TPM initialization delay, so that the TPM is ready before IMA.  After
> James' patch that wasn't needed anymore.
> 
> Looking back at this thread, I see you're using systemd-boot, not
> grub2.  When you commented out the systemd-boot timeout, IMA found the
> TPM.  The question is why isn't the TPM ready with the timeout before
> IMA (like above)?  Has systemd-boot done the selftest?

I am not sure wether systemd-boot touches TPM at all but I get the same
behaviour with syslinux-efi.

> 
> Mimi
> 

Re: tpm_tis TPM2.0 not detected on cold boot

[Mimi Zohar]

On Tue, 2019-01-01 at 17:15 +0100, Michael Niewöhner wrote:
> On Mon, 2018-12-31 at 16:17 -0500, Mimi Zohar wrote:
> > On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote:
> > 
> > > > difference is that on a cold boot, the TPM takes longer to initialize.
> > > 
> > > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager
> > > does
> > > not solve the problem. So the problem is NOT that the TPM takes longer to
> > > initialize. Even adding a delay of 20 seconds before TPM init does not solve
> > > that while that should be more than enough time.
> > 
> > The purpose of commenting out the TPM2 selftest was to minimize the
> > TPM initialization delay, so that the TPM is ready before IMA.  After
> > James' patch that wasn't needed anymore.
> > 
> > Looking back at this thread, I see you're using systemd-boot, not
> > grub2.  When you commented out the systemd-boot timeout, IMA found the
> > TPM.  The question is why isn't the TPM ready with the timeout before
> > IMA (like above)?  Has systemd-boot done the selftest?
> 
> I am not sure wether systemd-boot touches TPM at all but I get the same
> behaviour with syslinux-efi.

From looking at the source code, it depends on whether systemd was
compiled with ENABLE_TPM enabled(eg. src/boot/efi/boot.c,
src/boot/efi/measure.c, src/boot/efi/stub.c).

Mimi

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Tue, 2019-01-01 at 11:38 -0500, Mimi Zohar wrote:
> On Tue, 2019-01-01 at 17:15 +0100, Michael Niewöhner wrote:
> > On Mon, 2018-12-31 at 16:17 -0500, Mimi Zohar wrote:
> > > On Sun, 2018-12-30 at 14:22 +0100, Michael Niewöhner wrote:
> > > 
> > > > > difference is that on a cold boot, the TPM takes longer to initialize.
> > > > 
> > > > Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot
> > > > manager
> > > > does
> > > > not solve the problem. So the problem is NOT that the TPM takes longer
> > > > to
> > > > initialize. Even adding a delay of 20 seconds before TPM init does not
> > > > solve
> > > > that while that should be more than enough time.
> > > 
> > > The purpose of commenting out the TPM2 selftest was to minimize the
> > > TPM initialization delay, so that the TPM is ready before IMA.  After
> > > James' patch that wasn't needed anymore.
> > > 
> > > Looking back at this thread, I see you're using systemd-boot, not
> > > grub2.  When you commented out the systemd-boot timeout, IMA found the
> > > TPM.  The question is why isn't the TPM ready with the timeout before
> > > IMA (like above)?  Has systemd-boot done the selftest?
> > 
> > I am not sure wether systemd-boot touches TPM at all but I get the same
> > behaviour with syslinux-efi.
> 
> From looking at the source code, it depends on whether systemd was
> compiled with ENABLE_TPM enabled(eg. src/boot/efi/boot.c,
> src/boot/efi/measure.c, src/boot/efi/stub.c).

Debian build it with TPM enabled. I just checked syslinux-efi which does not do
anything TPM-related.

> 
> Mimi
> 

Re: tpm_tis TPM2.0 not detected on cold boot

[Ken Goldman]

On 12/29/2018 10:33 PM, Mimi Zohar wrote:
> But the problem you've described is on a cold boot, not a soft reboot.
>   Both the soft reboot and kexec are working properly.  It seems the
> difference is that on a cold boot, the TPM takes longer to initialize.

I would expect this.

The TPM doesn't even see a 'soft reboot' right?

OTOH, a 'cold boot' hits the TPM Init pin, which causes the take several
actions.  Probably the one with the most impact is resetting the state
of self test.  Thus, the TPM will require a function to be self tested
before it can be used, adding delays.

Re: tpm_tis TPM2.0 not detected on cold boot

[Jarkko Sakkinen]

On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> There is another issue but I don't know if both are related. Maybe that's just a
> timing issue...
> 
> root@debian:~# dd if=/dev/hwrng bs=1 count=1
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755958 s, 0.0 kB/s
> root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
> count=1 | xxd
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755697 s, 0.0 kB/s
> 1+0 records in
> 1+0 records out
> 00000000: 52                                       R
> 1 byte copied, 0.0106268 s, 0.1 kB/s
> 
> 
> Michael

What does /sys/devices/virtual/misc/hw_random/rng_current show?

Did run commands as a sanity check on my laptop and seem to work.

/Jarkko

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > There is another issue but I don't know if both are related. Maybe that's
> > just a
> > timing issue...
> > 
> > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > dd: error reading '/dev/hwrng': Operation not permitted
> > 0+0 records in
> > 0+0 records out
> > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
> > count=1 | xxd
> > dd: error reading '/dev/hwrng': Operation not permitted
> > 0+0 records in
> > 0+0 records out
> > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > 1+0 records in
> > 1+0 records out
> > 00000000: 52                                       R
> > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > 
> > 
> > Michael
> 
> What does /sys/devices/virtual/misc/hw_random/rng_current show?
> 
> Did run commands as a sanity check on my laptop and seem to work.
> 
> /Jarkko

rng_current says "tpm-rng-0", which should be correct


Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Jarkko Sakkinen]

On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > There is another issue but I don't know if both are related. Maybe that's
> > > just a
> > > timing issue...
> > > 
> > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > dd: error reading '/dev/hwrng': Operation not permitted
> > > 0+0 records in
> > > 0+0 records out
> > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
> > > count=1 | xxd
> > > dd: error reading '/dev/hwrng': Operation not permitted
> > > 0+0 records in
> > > 0+0 records out
> > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > 1+0 records in
> > > 1+0 records out
> > > 00000000: 52                                       R
> > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > 
> > > 
> > > Michael
> > 
> > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > 
> > Did run commands as a sanity check on my laptop and seem to work.
> > 
> > /Jarkko
> 
> rng_current says "tpm-rng-0", which should be correct

Is /dev/tpm0 accessible and usable?

/Jarkko

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > There is another issue but I don't know if both are related. Maybe
> > > > that's
> > > > just a
> > > > timing issue...
> > > > 
> > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > 0+0 records in
> > > > 0+0 records out
> > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng
> > > > bs=1
> > > > count=1 | xxd
> > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > 0+0 records in
> > > > 0+0 records out
> > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > 1+0 records in
> > > > 1+0 records out
> > > > 00000000: 52                                       R
> > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > 
> > > > 
> > > > Michael
> > > 
> > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > 
> > > Did run commands as a sanity check on my laptop and seem to work.
> > > 
> > > /Jarkko
> > 
> > rng_current says "tpm-rng-0", which should be correct
> 
> Is /dev/tpm0 accessible and usable?
> 
> /Jarkko

No, it does not seem to work:

root@debian:~# tpm_version                                     
Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
Communication failure
root@debian:~# tcsd -f
TCSD TDDL ioctl: (25) Inappropriate ioctl for device
TCSD TDDL Falling back to Read/Write device support.
TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
root@debian:~# stat /dev/tpm0
  File: /dev/tpm0
  Size: 0         	Blocks: 0          IO Block: 4096   character special
file
Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
Access: 2019-01-03 16:39:20.627635333 +0100
Modify: 2019-01-03 16:39:20.627635333 +0100
Change: 2019-01-03 16:39:20.627635333 +0100
 Birth: -

Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote:
> On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > > There is another issue but I don't know if both are related. Maybe
> > > > > that's
> > > > > just a
> > > > > timing issue...
> > > > > 
> > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > 0+0 records in
> > > > > 0+0 records out
> > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng
> > > > > bs=1
> > > > > count=1 | xxd
> > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > 0+0 records in
> > > > > 0+0 records out
> > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > > 1+0 records in
> > > > > 1+0 records out
> > > > > 00000000: 52                                       R
> > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > > 
> > > > > 
> > > > > Michael
> > > > 
> > > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > > 
> > > > Did run commands as a sanity check on my laptop and seem to work.
> > > > 
> > > > /Jarkko
> > > 
> > > rng_current says "tpm-rng-0", which should be correct
> > 
> > Is /dev/tpm0 accessible and usable?
> > 
> > /Jarkko
> 
> No, it does not seem to work:
> 
> root@debian:~# tpm_version                                     
> Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
> Communication failure
> root@debian:~# tcsd -f
> TCSD TDDL ioctl: (25) Inappropriate ioctl for device
> TCSD TDDL Falling back to Read/Write device support.
> TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
> TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
> root@debian:~# stat /dev/tpm0
>   File: /dev/tpm0
>   Size: 0         	Blocks: 0          IO Block: 4096   character special
> file
> Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
> Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
> Access: 2019-01-03 16:39:20.627635333 +0100
> Modify: 2019-01-03 16:39:20.627635333 +0100
> Change: 2019-01-03 16:39:20.627635333 +0100
>  Birth: -
> 
> Michael


I have done some more tests with tpm2-tests from 
https://github.com/jethrogb/tpm2-utils.
These are my results:


(initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type
Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted

(initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0 vendor_
tpm_type
Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted
�   
nitramfs) 

-> Same symptom like with dd if=/dev/tpm....


Trying to read the firmware version:

(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 firmwa
re_version_1;) 2>/dev/null | hexdump -C
00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06 00  |................|
00000010  00 00 01 00 00 01 0b 00  01 00 03                 |...........|
0000001b

(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 firmwa
re_version_2;) 2>/dev/null | hexdump -C
00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06 00  |................|
00000010  00 00 01 00 00 01 0c 00  02 00 08                 |...........|
0000001b

-> This version numbers are correct, 1.3.2.8 indeed is the current flashed
firmware.


Get the vendor strings:

(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor
_string_1;) 2>/dev/null | xxd
00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
00000010: 0000 0100 0001 0672 6c73 00              .......rls.
(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor
_string_2;) 2>/dev/null | xxd
00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
00000010: 0000 0100 0001 074e 5043 54              .......NPCT
(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor
_string_3;) 2>/dev/null | xxd
00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
00000010: 0000 0100 0001 0820 0000 00              ....... ...
(initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0 vendor
_string_4;) 2>/dev/null | xxd
00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
00000010: 0000 0100 0001 0920 0000 00              ....... ...

Well, NPCT is correct...



Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Fri, 2019-01-04 at 12:58 +0100, Michael Niewöhner wrote:
> On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote:
> > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > > > There is another issue but I don't know if both are related. Maybe
> > > > > > that's
> > > > > > just a
> > > > > > timing issue...
> > > > > > 
> > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > 0+0 records in
> > > > > > 0+0 records out
> > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng
> > > > > > bs=1
> > > > > > count=1 | xxd
> > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > 0+0 records in
> > > > > > 0+0 records out
> > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > > > 1+0 records in
> > > > > > 1+0 records out
> > > > > > 00000000: 52                                       R
> > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > > > 
> > > > > > 
> > > > > > Michael
> > > > > 
> > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > > > 
> > > > > Did run commands as a sanity check on my laptop and seem to work.
> > > > > 
> > > > > /Jarkko
> > > > 
> > > > rng_current says "tpm-rng-0", which should be correct
> > > 
> > > Is /dev/tpm0 accessible and usable?
> > > 
> > > /Jarkko
> > 
> > No, it does not seem to work:
> > 
> > root@debian:~# tpm_version                                     
> > Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
> > Communication failure
> > root@debian:~# tcsd -f
> > TCSD TDDL ioctl: (25) Inappropriate ioctl for device
> > TCSD TDDL Falling back to Read/Write device support.
> > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
> > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
> > root@debian:~# stat /dev/tpm0
> >   File: /dev/tpm0
> >   Size: 0         	Blocks: 0          IO Block: 4096   character special
> > file
> > Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
> > Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
> > Access: 2019-01-03 16:39:20.627635333 +0100
> > Modify: 2019-01-03 16:39:20.627635333 +0100
> > Change: 2019-01-03 16:39:20.627635333 +0100
> >  Birth: -
> > 
> > Michael
> 
> I have done some more tests with tpm2-tests from 
> https://github.com/jethrogb/tpm2-utils.
> These are my results:
> 
> 
> (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type
> Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted
> 
> (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0
> vendor_
> tpm_type
> Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted
> �   
> nitramfs) 
> 
> -> Same symptom like with dd if=/dev/tpm....
> 
> 
> Trying to read the firmware version:
> 
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> firmwa
> re_version_1;) 2>/dev/null | hexdump -C
> 00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06 00  |................|
> 00000010  00 00 01 00 00 01 0b 00  01 00 03                 |...........|
> 0000001b
> 
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> firmwa
> re_version_2;) 2>/dev/null | hexdump -C
> 00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06 00  |................|
> 00000010  00 00 01 00 00 01 0c 00  02 00 08                 |...........|
> 0000001b
> 
> -> This version numbers are correct, 1.3.2.8 indeed is the current flashed
> firmware.
> 
> 
> Get the vendor strings:
> 
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> vendor
> _string_1;) 2>/dev/null | xxd
> 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> 00000010: 0000 0100 0001 0672 6c73 00              .......rls.
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> vendor
> _string_2;) 2>/dev/null | xxd
> 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> 00000010: 0000 0100 0001 074e 5043 54              .......NPCT
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> vendor
> _string_3;) 2>/dev/null | xxd
> 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> 00000010: 0000 0100 0001 0820 0000 00              ....... ...
> (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> vendor
> _string_4;) 2>/dev/null | xxd
> 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> 00000010: 0000 0100 0001 0920 0000 00              ....... ...
> 
> Well, NPCT is correct...
> 
> 
> 
> Michael

Oh damn. I wasn not aware that trousers/tcsd does only support TPM<=1.2.
Instead of trousers I now tested tpm2-tools and tss2.
Guess what? Same symptoms... This is definitely some sort of timing issue...


root@debian:~# tpm2_nvlist 
ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation not
permitted 
ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number of
bytes written. Expected 22, wrote 0. 
ERROR: GetCapability:Get NV Index list Error. TPM Error:0xa000a
ERROR: Unable to run tpm2_nvlist
root@debian:~# tpm2_nvlist; tpm2_nvlist
ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation not
permitted 
ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number of
bytes written. Expected 22, wrote 0. 
ERROR: GetCapability:Get NV Index list Error. TPM Error:0xa000a
ERROR: Unable to run tpm2_nvlist
0x1800001:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly:
authwrite|policydelete|writelocked|writedefine|authread|no_da|written|platformcr
eate
    value: 0x42C0462
  size: 70
........

root@debian:~# tpm2_pcrlist
ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation not
permitted 
ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number of
bytes written. Expected 22, wrote 0. 
ERROR: GetCapability: Get PCR allocation status Error. TPM Error:0xa000a......
ERROR: Unable to run tpm2_pcrlist
root@debian:~# tpm2_pcrlist; tpm2_pcrlist 
sha1 :
  0  : 1ebb2be3b7103a09b5caeeb5827c1242cd6632ec
  1  : 425e833da73cb511150d6ffcf6fac64e9a6feb58
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : d13c141b174afbb568773adf1f39940a2df47c7d
  5  : 756a3647403ab141ec2c1ac7325854f4a93f6efd
......


Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Fri, 2019-01-04 at 16:28 +0100, Michael Niewöhner wrote:
> On Fri, 2019-01-04 at 12:58 +0100, Michael Niewöhner wrote:
> > On Thu, 2019-01-03 at 16:47 +0100, Michael Niewöhner wrote:
> > > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > > > > There is another issue but I don't know if both are related. Maybe
> > > > > > > that's
> > > > > > > just a
> > > > > > > timing issue...
> > > > > > > 
> > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > > 0+0 records in
> > > > > > > 0+0 records out
> > > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd
> > > > > > > if=/dev/hwrng
> > > > > > > bs=1
> > > > > > > count=1 | xxd
> > > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > > 0+0 records in
> > > > > > > 0+0 records out
> > > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > > > > 1+0 records in
> > > > > > > 1+0 records out
> > > > > > > 00000000: 52                                       R
> > > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > > > > 
> > > > > > > 
> > > > > > > Michael
> > > > > > 
> > > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > > > > 
> > > > > > Did run commands as a sanity check on my laptop and seem to work.
> > > > > > 
> > > > > > /Jarkko
> > > > > 
> > > > > rng_current says "tpm-rng-0", which should be correct
> > > > 
> > > > Is /dev/tpm0 accessible and usable?
> > > > 
> > > > /Jarkko
> > > 
> > > No, it does not seem to work:
> > > 
> > > root@debian:~# tpm_version                                     
> > > Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
> > > Communication failure
> > > root@debian:~# tcsd -f
> > > TCSD TDDL ioctl: (25) Inappropriate ioctl for device
> > > TCSD TDDL Falling back to Read/Write device support.
> > > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
> > > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
> > > root@debian:~# stat /dev/tpm0
> > >   File: /dev/tpm0
> > >   Size: 0         	Blocks: 0          IO Block: 4096   character
> > > special
> > > file
> > > Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
> > > Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
> > > Access: 2019-01-03 16:39:20.627635333 +0100
> > > Modify: 2019-01-03 16:39:20.627635333 +0100
> > > Change: 2019-01-03 16:39:20.627635333 +0100
> > >  Birth: -
> > > 
> > > Michael
> > 
> > I have done some more tests with tpm2-tests from 
> > https://github.com/jethrogb/tpm2-utils.
> > These are my results:
> > 
> > 
> > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type
> > Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted
> > 
> > (initramfs) ./tpm2-test /dev/tpm0 vendor_tpm_type; ./tpm2-test /dev/tpm0
> > vendor_
> > tpm_type
> > Error on write(fd,(char*)&tpm_cmd,sizeof(tpm_cmd)): Operation not permitted
> > �   
> > nitramfs) 
> > 
> > -> Same symptom like with dd if=/dev/tpm....
> > 
> > 
> > Trying to read the firmware version:
> > 
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > firmwa
> > re_version_1;) 2>/dev/null | hexdump -C
> > 00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06
> > 00  |................|
> > 00000010  00 00 01 00 00 01 0b 00  01 00 03                 |...........|
> > 0000001b
> > 
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > firmwa
> > re_version_2;) 2>/dev/null | hexdump -C
> > 00000000  80 01 00 00 00 1b 00 00  00 00 01 00 00 00 06
> > 00  |................|
> > 00000010  00 00 01 00 00 01 0c 00  02 00 08                 |...........|
> > 0000001b
> > 
> > -> This version numbers are correct, 1.3.2.8 indeed is the current flashed
> > firmware.
> > 
> > 
> > Get the vendor strings:
> > 
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > vendor
> > _string_1;) 2>/dev/null | xxd
> > 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> > 00000010: 0000 0100 0001 0672 6c73 00              .......rls.
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > vendor
> > _string_2;) 2>/dev/null | xxd
> > 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> > 00000010: 0000 0100 0001 074e 5043 54              .......NPCT
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > vendor
> > _string_3;) 2>/dev/null | xxd
> > 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> > 00000010: 0000 0100 0001 0820 0000 00              ....... ...
> > (initramfs) (./tpm2-test /dev/tpm0 vendor_string_1; ./tpm2-test /dev/tpm0
> > vendor
> > _string_4;) 2>/dev/null | xxd
> > 00000000: 8001 0000 001b 0000 0000 0100 0000 0600  ................
> > 00000010: 0000 0100 0001 0920 0000 00              ....... ...
> > 
> > Well, NPCT is correct...
> > 
> > 
> > 
> > Michael
> 
> Oh damn. I wasn not aware that trousers/tcsd does only support TPM<=1.2.
> Instead of trousers I now tested tpm2-tools and tss2.
> Guess what? Same symptoms... This is definitely some sort of timing issue...
> 
> 
> root@debian:~# tpm2_nvlist 
> ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation
> not
> permitted 
> ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number
> of
> bytes written. Expected 22, wrote 0. 
> ERROR: GetCapability:Get NV Index list Error. TPM Error:0xa000a
> ERROR: Unable to run tpm2_nvlist
> root@debian:~# tpm2_nvlist; tpm2_nvlist
> ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation
> not
> permitted 
> ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number
> of
> bytes written. Expected 22, wrote 0. 
> ERROR: GetCapability:Get NV Index list Error. TPM Error:0xa000a
> ERROR: Unable to run tpm2_nvlist
> 0x1800001:
>   hash algorithm:
>     friendly: sha256
>     value: 0xB
>   attributes:
>     friendly:
> authwrite|policydelete|writelocked|writedefine|authread|no_da|written|platform
> cr
> eate
>     value: 0x42C0462
>   size: 70
> ........
> 
> root@debian:~# tpm2_pcrlist
> ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation
> not
> permitted 
> ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number
> of
> bytes written. Expected 22, wrote 0. 
> ERROR: GetCapability: Get PCR allocation status Error. TPM Error:0xa000a......
> ERROR: Unable to run tpm2_pcrlist
> root@debian:~# tpm2_pcrlist; tpm2_pcrlist 
> sha1 :
>   0  : 1ebb2be3b7103a09b5caeeb5827c1242cd6632ec
>   1  : 425e833da73cb511150d6ffcf6fac64e9a6feb58
>   2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
>   3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
>   4  : d13c141b174afbb568773adf1f39940a2df47c7d
>   5  : 756a3647403ab141ec2c1ac7325854f4a93f6efd
> ......
> 
> 
> Michael


Some straces for working vs non-working calls (I removed lib loading, many
identical lines etc. for better readability):

> strace -f -o /tmp/dbg3 tpm2_pcrlist  # NON-WORKING
execve("/usr/bin/tpm2_pcrlist", ["tpm2_pcrlist"], 0x7fff5eb48698 /* 11 vars */)
= 0
<...>
openat(AT_FDCWD, "/dev/tpm0", O_RDWR|O_NONBLOCK) = 3
write(3, "\200\1\0\0\0\26\0\0\1z\0\0\0\5\0\0\0\0\0\0\0\1", 22) = -1 EPERM
(Operation not permitted)
write(2, "ERROR:tcti:src/util/io.c:102:wri"..., 91) = 91
write(2, "ERROR:tcti:src/tss2-tcti/tcti-de"..., 119) = 119
write(2, "ERROR: ", 7)            = 7
write(2, "GetCapability: Get PCR allocatio"..., 71) = 71
write(2, "\n", 1)                 = 1
write(2, "ERROR: ", 7)            = 7
write(2, "Unable to run tpm2_pcrlist", 26) = 26
write(2, "\n", 1)                 = 1
close(3)                          = 0
munmap(0x7f64f0ec9000, 24856)     = 0
exit_group(1)                     = ?
+++ exited with 1 +++

> tpm2_pcrlist; strace -f -o /tmp/dbg4 tpm2_pcrlist  # WORKING
execve("/usr/bin/tpm2_pcrlist", ["tpm2_pcrlist"], 0x7ffef20135f8 /* 11 vars */)
= 0
<...>
openat(AT_FDCWD, "/dev/tpm0", O_RDWR|O_NONBLOCK) = 3
write(3, "\200\1\0\0\0\26\0\0\1z\0\0\0\5\0\0\0\0\0\0\0\1", 22) = 22
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\1\0\0\0\37\0\0\0\0\0\0\0\0\5\0\0\0\2\0\4\3\377\377\377\0\v\3\377\377\377",
4096) = 31
write(3, "\200\1\0\0\0\32\0\0\1~\0\0\0\2\0\4\3\377\377\377\0\v\3\377\377\377",
26) = 26
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\1\0\0\0\322\0\0\0\0\0\0\0F\0\0\0\2\0\4\3\377\0\0\0\v\3\0\0\0\0\0"...,
4096) = 210
write(3, "\200\1\0\0\0\32\0\0\1~\0\0\0\2\0\4\3\0\377\377\0\v\3\377\377\377", 26)
= 26
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\1\0\0\0\322\0\0\0\0\0\0\0F\0\0\0\2\0\4\3\0\377\0\0\v\3\0\0\0\0\0"...,
4096) = 210
<...>
write(1, "sha1 :\n", 7)           = 7
write(1, "  0  : 1ebb2be3b7103a09b5caeeb58"..., 48) = 48
write(1, "  1  : d3ac8d9c97272d8ea1c8443dc"..., 48) = 48
write(1, "  2  : b2a83b0ebf2f8374299a5b2bd"..., 48) = 48
<...>
write(1, "  23 : 0000000000000000000000000"..., 72) = 72
close(3)                          = 0
munmap(0x7f2bbebcf000, 24856)     = 0
exit_group(0)                     = ?
+++ exited with 0 +++


> strace -f -o /tmp/dbg1 dd if=/dev/hwrng of=/dev/null bs=1 count=1  # NON-
WORKING
execve("/bin/dd", ["dd", "if=/dev/hwrng", "of=/dev/null", "bs=1", "count=1"],
0x7ffd5cf74948 /* 11 vars */) = 0
<...>
openat(AT_FDCWD, "/dev/hwrng", O_RDONLY) = 3
dup2(3, 0)                        = 0
close(3)                          = 0
lseek(0, 0, SEEK_CUR)             = 0
openat(AT_FDCWD, "/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
dup2(3, 1)                        = 1
close(3)                          = 0
read(0, 0x555e67d1a000, 1)        = -1 EPERM (Operation not permitted)
write(2, "dd: ", 4)               = 4
write(2, "error reading '/dev/hwrng'", 26) = 26
write(2, ": Operation not permitted", 25) = 25
write(2, "\n", 1)                 = 1
close(0)                          = 0
close(1)                          = 0
write(2, "0+0 records in\n0+0 records out\n", 31) = 31
write(2, "0 bytes copied, 0.75088 s, 0.0 k"..., 35) = 35
write(2, "\n", 1)                 = 1
close(2)                          = 0
exit_group(1)                     = ?
+++ exited with 1 +++


> dd if=/dev/hwrng of=/dev/null bs=1 count=1; tpm2_pcrlist; strace -f -o
/tmp/dbg2 dd if=/dev/hwrng of=/dev/null bs=1 count=1  # WORKING
execve("/bin/dd", ["dd", "if=/dev/hwrng", "of=/dev/null", "bs=1", "count=1"], 0x7ffd880f4cc8 /* 11 vars */) = 0
<...>
openat(AT_FDCWD, "/dev/hwrng", O_RDONLY) = 3
dup2(3, 0)                        = 0
close(3)                          = 0
lseek(0, 0, SEEK_CUR)             = 0
openat(AT_FDCWD, "/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
dup2(3, 1)                        = 1
close(3)                          = 0
read(0, "\242", 1)                = 1
write(1, "\242", 1)               = 1
close(0)                          = 0
close(1)                          = 0
write(2, "1+0 records in\n1+0 records out\n", 31) = 31
write(2, "1 byte copied, 0.000110891 s, 9."..., 38) = 38
write(2, "\n", 1)                 = 1
close(2)                          = 0
exit_group(0)                     = ?
+++ exited with 0 +++


Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Jarkko Sakkinen]

On Fri, Jan 04, 2019 at 04:28:24PM +0100, Michael Niewöhner wrote:
> root@debian:~# tpm2_pcrlist
> ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation not
> permitted 
> ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong number of
> bytes written. Expected 22, wrote 0. 
> ERROR: GetCapability: Get PCR allocation status Error. TPM Error:0xa000a......
> ERROR: Unable to run tpm2_pcrlist
> root@debian:~# tpm2_pcrlist; tpm2_pcrlist 
> sha1 :
>   0  : 1ebb2be3b7103a09b5caeeb5827c1242cd6632ec
>   1  : 425e833da73cb511150d6ffcf6fac64e9a6feb58
>   2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
>   3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
>   4  : d13c141b174afbb568773adf1f39940a2df47c7d
>   5  : 756a3647403ab141ec2c1ac7325854f4a93f6efd
> ......

So the sympton is that it from time to time works and time to time
fails.

Can't recall whether you had interrupts enabled or disabled for the
TPM chip (depending on whether you use IRQs or polling you'd have
to tweak the code from a different place), but you could tweak
directly the TPM2_DURATION_* constants in drivers/char/tpm/tpm.h:

enum tpm2_timeouts {
	TPM2_TIMEOUT_A          =    750,
	TPM2_TIMEOUT_B          =   2000,
	TPM2_TIMEOUT_C          =    200,
	TPM2_TIMEOUT_D          =     30,
	TPM2_DURATION_SHORT     =     20,
	TPM2_DURATION_MEDIUM    =    750,
	TPM2_DURATION_LONG      =   2000,
	TPM2_DURATION_LONG_LONG = 300000,
	TPM2_DURATION_DEFAULT   = 120000,
};

Set SHORT, LONG and MEDIUM to lets say 3000 and lets see if that
makes a difference or not.

/Jarkko

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-10 at 19:28 +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 04, 2019 at 04:28:24PM +0100, Michael Niewöhner wrote:
> > root@debian:~# tpm2_pcrlist
> > ERROR:tcti:src/util/io.c:102:write_all() failed to write to fd 3: Operation
> > not
> > permitted 
> > ERROR:tcti:src/tss2-tcti/tcti-device.c:86:tcti_device_transmit() wrong
> > number of
> > bytes written. Expected 22, wrote 0. 
> > ERROR: GetCapability: Get PCR allocation status Error. TPM
> > Error:0xa000a......
> > ERROR: Unable to run tpm2_pcrlist
> > root@debian:~# tpm2_pcrlist; tpm2_pcrlist 
> > sha1 :
> >   0  : 1ebb2be3b7103a09b5caeeb5827c1242cd6632ec
> >   1  : 425e833da73cb511150d6ffcf6fac64e9a6feb58
> >   2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
> >   3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
> >   4  : d13c141b174afbb568773adf1f39940a2df47c7d
> >   5  : 756a3647403ab141ec2c1ac7325854f4a93f6efd
> > ......
> 
> So the sympton is that it from time to time works and time to time
> fails.

Not exactly. It only works on the second of two directly consecutive calls. 

> 
> Can't recall whether you had interrupts enabled or disabled for the
> TPM chip (depending on whether you use IRQs or polling you'd have
> to tweak the code from a different place), but you could tweak
> directly the TPM2_DURATION_* constants in drivers/char/tpm/tpm.h:
> 
> enum tpm2_timeouts {
> 	TPM2_TIMEOUT_A          =    750,
> 	TPM2_TIMEOUT_B          =   2000,
> 	TPM2_TIMEOUT_C          =    200,
> 	TPM2_TIMEOUT_D          =     30,
> 	TPM2_DURATION_SHORT     =     20,
> 	TPM2_DURATION_MEDIUM    =    750,
> 	TPM2_DURATION_LONG      =   2000,
> 	TPM2_DURATION_LONG_LONG = 300000,
> 	TPM2_DURATION_DEFAULT   = 120000,
> };
> 
> Set SHORT, LONG and MEDIUM to lets say 3000 and lets see if that
> makes a difference or not.
> /Jarkko


I have already tried this but there was not any difference.

Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Jarkko Sakkinen]

On Thu, Jan 03, 2019 at 04:47:31PM +0100, Michael Niewöhner wrote:
> On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > > There is another issue but I don't know if both are related. Maybe
> > > > > that's
> > > > > just a
> > > > > timing issue...
> > > > > 
> > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > 0+0 records in
> > > > > 0+0 records out
> > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng
> > > > > bs=1
> > > > > count=1 | xxd
> > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > 0+0 records in
> > > > > 0+0 records out
> > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > > 1+0 records in
> > > > > 1+0 records out
> > > > > 00000000: 52                                       R
> > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > > 
> > > > > 
> > > > > Michael
> > > > 
> > > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > > 
> > > > Did run commands as a sanity check on my laptop and seem to work.
> > > > 
> > > > /Jarkko
> > > 
> > > rng_current says "tpm-rng-0", which should be correct
> > 
> > Is /dev/tpm0 accessible and usable?
> > 
> > /Jarkko
> 
> No, it does not seem to work:
> 
> root@debian:~# tpm_version                                     
> Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
> Communication failure
> root@debian:~# tcsd -f
> TCSD TDDL ioctl: (25) Inappropriate ioctl for device
> TCSD TDDL Falling back to Read/Write device support.
> TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
> TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
> root@debian:~# stat /dev/tpm0
>   File: /dev/tpm0
>   Size: 0         	Blocks: 0          IO Block: 4096   character special
> file
> Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
> Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
> Access: 2019-01-03 16:39:20.627635333 +0100
> Modify: 2019-01-03 16:39:20.627635333 +0100
> Change: 2019-01-03 16:39:20.627635333 +0100
>  Birth: -

But those tools should not work because TrouSerS is for TPM 1.2.

/Jarkko

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-10 at 19:19 +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 03, 2019 at 04:47:31PM +0100, Michael Niewöhner wrote:
> > On Thu, 2019-01-03 at 17:04 +0200, Jarkko Sakkinen wrote:
> > > On Thu, Jan 03, 2019 at 02:38:11PM +0100, Michael Niewöhner wrote:
> > > > On Thu, 2019-01-03 at 15:27 +0200, Jarkko Sakkinen wrote:
> > > > > On Sun, Dec 23, 2018 at 12:55:12PM +0100, Michael Niewöhner wrote:
> > > > > > There is another issue but I don't know if both are related. Maybe
> > > > > > that's
> > > > > > just a
> > > > > > timing issue...
> > > > > > 
> > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1
> > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > 0+0 records in
> > > > > > 0+0 records out
> > > > > > 0 bytes copied, 0.755958 s, 0.0 kB/s
> > > > > > root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng
> > > > > > bs=1
> > > > > > count=1 | xxd
> > > > > > dd: error reading '/dev/hwrng': Operation not permitted
> > > > > > 0+0 records in
> > > > > > 0+0 records out
> > > > > > 0 bytes copied, 0.755697 s, 0.0 kB/s
> > > > > > 1+0 records in
> > > > > > 1+0 records out
> > > > > > 00000000: 52                                       R
> > > > > > 1 byte copied, 0.0106268 s, 0.1 kB/s
> > > > > > 
> > > > > > 
> > > > > > Michael
> > > > > 
> > > > > What does /sys/devices/virtual/misc/hw_random/rng_current show?
> > > > > 
> > > > > Did run commands as a sanity check on my laptop and seem to work.
> > > > > 
> > > > > /Jarkko
> > > > 
> > > > rng_current says "tpm-rng-0", which should be correct
> > > 
> > > Is /dev/tpm0 accessible and usable?
> > > 
> > > /Jarkko
> > 
> > No, it does not seem to work:
> > 
> > root@debian:~# tpm_version                                     
> > Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
> > Communication failure
> > root@debian:~# tcsd -f
> > TCSD TDDL ioctl: (25) Inappropriate ioctl for device
> > TCSD TDDL Falling back to Read/Write device support.
> > TCSD TDDL ERROR: write to device /dev/tpm0 failed: Operation not permitted
> > TCSD TCS ERROR: TCS GetCapability failed with result = 0x1087
> > root@debian:~# stat /dev/tpm0
> >   File: /dev/tpm0
> >   Size: 0         	Blocks: 0          IO Block: 4096   character special
> > file
> > Device: 6h/6d	Inode: 1114        Links: 1     Device type: a,e0
> > Access: (0600/crw-------)  Uid: (  104/     tss)   Gid: (  112/     tss)
> > Access: 2019-01-03 16:39:20.627635333 +0100
> > Modify: 2019-01-03 16:39:20.627635333 +0100
> > Change: 2019-01-03 16:39:20.627635333 +0100
> >  Birth: -
> 
> But those tools should not work because TrouSerS is for TPM 1.2.
> 
> /Jarkko


Right. I realized that too late... Have a look at my email from Fri, 04 Jan 2019
19:26:10 +0100

Michael

Re: tpm_tis TPM2.0 not detected on cold boot

[Jarkko Sakkinen]

On Sun, Dec 16, 2018 at 02:32:38PM +0100, Michael Niewöhner wrote:
 
> dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1:
> ----------------------------------------------------------
> > dmesg | grep -i tpm
> [    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> [    0.000000] efi:  ACPI
> 2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
> 3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bb018 
> [    0.003531] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
> S06   00001260 AMI  00000000)
> [    0.162005] Kernel command line: initrd=\initrd-test console=ttyS0,115200n8
> break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> [    3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)
> [    3.683117] tpm_tis tpm_tis: can't request region for resource [mem
> 0xfed40000-0xfed44fff]
> [    3.691378] tpm_tis: probe of tpm_tis failed with error -16
> [    4.572539] ima: Error Communicating to TPM chip

Wonder why this happens. What does /proc/iomem show?

/Jarkko

Re: tpm_tis TPM2.0 not detected on cold boot

[Michael Niewöhner]

On Thu, 2019-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
> On Sun, Dec 16, 2018 at 02:32:38PM +0100, Michael Niewöhner wrote:
>  
> > dmesg cold boot with tpm_tis.interrupts=0 tpm_tis.force=1:
> > ----------------------------------------------------------
> > > dmesg | grep -i tpm
> > [    0.000000] Command line: initrd=\initrd-test console=ttyS0,115200n8
> > break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> > [    0.000000] efi:  ACPI
> > 2.0=0x9e07e000  ACPI=0x9e07e000  SMBIOS=0x9ebeb000  SMBIOS
> > 3.0=0x9ebea000  MEMATTR=0x98fb2018  TPMEventLog=0x972bb018 
> > [    0.003531] ACPI: TPM2 0x000000009E0B7F70 000034 (v03 LENOVO TC-
> > S06   00001260 AMI  00000000)
> > [    0.162005] Kernel command line: initrd=\initrd-test
> > console=ttyS0,115200n8
> > break=premount tpm_tis.interrupts=0 tpm_tis.force=1
> > [    3.616806] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 2)
> > [    3.683117] tpm_tis tpm_tis: can't request region for resource [mem
> > 0xfed40000-0xfed44fff]
> > [    3.691378] tpm_tis: probe of tpm_tis failed with error -16
> > [    4.572539] ima: Error Communicating to TPM chip
> 
> Wonder why this happens. What does /proc/iomem show?
> 
> /Jarkko

root@debian:~# cat /proc/iomem 
00000000-00000fff : Reserved
00001000-00057fff : System RAM
00058000-00058fff : Reserved
00059000-0009dfff : System RAM
0009e000-000fffff : Reserved
  000a0000-000bffff : PCI Bus 0000:00
  000c0000-000c3fff : PCI Bus 0000:00
  000c4000-000c7fff : PCI Bus 0000:00
  000c8000-000cbfff : PCI Bus 0000:00
  000cc000-000cffff : PCI Bus 0000:00
  000d0000-000d3fff : PCI Bus 0000:00
  000d4000-000d7fff : PCI Bus 0000:00
  000d8000-000dbfff : PCI Bus 0000:00
  000dc000-000dffff : PCI Bus 0000:00
  000e0000-000e3fff : PCI Bus 0000:00
  000e4000-000e7fff : PCI Bus 0000:00
  000e8000-000ebfff : PCI Bus 0000:00
  000ec000-000effff : PCI Bus 0000:00
  000f0000-000fffff : System ROM
00100000-942eb017 : System RAM
942eb018-942fb457 : System RAM
942fb458-976bbfff : System RAM
976bc000-976bcfff : ACPI Non-volatile Storage
976bd000-976bdfff : Reserved
976be000-9d7fafff : System RAM
9d7fb000-9ea61fff : Reserved
  9dde3018-9dde3019 : APEI ERST
  9dde301c-9dde3021 : APEI ERST
  9dde3028-9dde3039 : APEI ERST
  9dde3040-9dde304c : APEI ERST
  9dde3050-9dde504f : APEI ERST
9ea62000-9eaedfff : ACPI Tables
9eaee000-9f2c7fff : ACPI Non-volatile Storage
9f2c8000-9f743fff : Reserved
9f744000-9f7fffff : System RAM
9f800000-9fffffff : Reserved
a0000000-dfffffff : PCI Bus 0000:00
  dfb00000-dfdfffff : PCI Bus 0000:03
    dfb00000-dfb7ffff : 0000:03:00.3
      dfb00000-dfb7ffff : igb
    dfb80000-dfbfffff : 0000:03:00.2
      dfb80000-dfbfffff : igb
    dfc00000-dfc7ffff : 0000:03:00.1
      dfc00000-dfc7ffff : igb
    dfc80000-dfcfffff : 0000:03:00.0
      dfc80000-dfcfffff : igb
    dfd00000-dfd03fff : 0000:03:00.3
      dfd00000-dfd03fff : igb
    dfd04000-dfd07fff : 0000:03:00.2
      dfd04000-dfd07fff : igb
    dfd08000-dfd0bfff : 0000:03:00.1
      dfd08000-dfd0bfff : igb
    dfd0c000-dfd0ffff : 0000:03:00.0
      dfd0c000-dfd0ffff : igb
  dfe00000-dfefffff : PCI Bus 0000:02
    dfe00000-dfe03fff : 0000:02:00.0
      dfe00000-dfe03fff : rtl_pci
  dff00000-dff1ffff : 0000:00:1f.6
    dff00000-dff1ffff : e1000e
  dff20000-dff23fff : 0000:00:1f.2
  dff24000-dff25fff : 0000:00:17.0
    dff24000-dff25fff : ahci
  dff26000-dff267ff : 0000:00:17.0
    dff26000-dff267ff : ahci
  dff27000-dff270ff : 0000:00:17.0
    dff27000-dff270ff : ahci
  dffe0000-dfffffff : pnp 00:06
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
  e0000000-efffffff : Reserved
    e0000000-efffffff : pnp 00:06
fd000000-fe7fffff : PCI Bus 0000:00
  fd000000-fdabffff : pnp 00:07
  fdac0000-fdacffff : pnp 00:09
  fdad0000-fdadffff : pnp 00:07
  fdae0000-fdaeffff : pnp 00:09
  fdaf0000-fdafffff : pnp 00:09
  fdb00000-fdffffff : pnp 00:07
    fdc6000c-fdc6000f : iTCO_wdt
      fdc6000c-fdc6000f : iTCO_wdt
  fe000000-fe010fff : Reserved
  fe036000-fe03bfff : pnp 00:07
  fe03d000-fe3fffff : pnp 00:07
  fe410000-fe7fffff : pnp 00:07
fec00000-fec00fff : Reserved
  fec00000-fec003ff : IOAPIC 0
fed00000-fed00fff : Reserved
  fed00000-fed003ff : HPET 0
    fed00000-fed003ff : PNP0103:00
fed10000-fed17fff : pnp 00:06
fed18000-fed18fff : pnp 00:06
fed19000-fed19fff : pnp 00:06
fed20000-fed3ffff : pnp 00:06
fed40000-fed44fff : MSFT0101:00
  fed40000-fed44fff : MSFT0101:00
fed45000-fed8ffff : pnp 00:06
fed90000-fed90fff : dmar0
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : Reserved
ff000000-ffffffff : Reserved
  ff000000-ffffffff : INT0800:00
    ff000000-ffffffff : pnp 00:06
100000000-85fffffff : System RAM
  2afc00000-2b06031d0 : Kernel code
  2b06031d1-2b0d120ff : Kernel data
  2b1119000-2b11fffff : Kernel bss
2000000000-2fffffffff : PCI Bus 0000:00
  2ffff00000-2ffff0ffff : 0000:00:14.0
    2ffff00000-2ffff0ffff : xhci-hcd
  2ffff10000-2ffff100ff : 0000:00:1f.4
  2ffff11000-2ffff11fff : 0000:00:14.2
    2ffff11000-2ffff11fff : Intel PCH thermal driver