* tpm_tis TPM2.0 not detected on cold boot @ 2018-12-16 13:32 Michael Niewöhner 2018-12-22 13:47 ` Michael Niewöhner 2019-01-03 13:41 ` Jarkko Sakkinen 0 siblings, 2 replies; 26+ messages in thread From: Michael Niewöhner @ 2018-12-16 13:32 UTC (permalink / raw) To: Jarkko Sakkinen, Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-16 13:32 tpm_tis TPM2.0 not detected on cold boot Michael Niewöhner @ 2018-12-22 13:47 ` Michael Niewöhner 2018-12-22 22:53 ` Mimi Zohar 2019-01-03 13:41 ` Jarkko Sakkinen 1 sibling, 1 reply; 26+ messages in thread From: Michael Niewöhner @ 2018-12-22 13:47 UTC (permalink / raw) To: Jarkko Sakkinen, Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-22 13:47 ` Michael Niewöhner @ 2018-12-22 22:53 ` Mimi Zohar 2018-12-23 11:55 ` Michael Niewöhner 0 siblings, 1 reply; 26+ messages in thread From: Mimi Zohar @ 2018-12-22 22:53 UTC (permalink / raw) To: Michael Niewöhner, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-22 22:53 ` Mimi Zohar @ 2018-12-23 11:55 ` Michael Niewöhner 2018-12-25 13:55 ` Michael Niewöhner 2019-01-03 13:27 ` Jarkko Sakkinen 0 siblings, 2 replies; 26+ messages in thread From: Michael Niewöhner @ 2018-12-23 11:55 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-23 11:55 ` Michael Niewöhner @ 2018-12-25 13:55 ` Michael Niewöhner 2018-12-30 3:33 ` Mimi Zohar 2019-01-03 13:27 ` Jarkko Sakkinen 1 sibling, 1 reply; 26+ messages in thread From: Michael Niewöhner @ 2018-12-25 13:55 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-25 13:55 ` Michael Niewöhner @ 2018-12-30 3:33 ` Mimi Zohar 2018-12-30 13:22 ` Michael Niewöhner 2018-12-31 17:56 ` Ken Goldman 0 siblings, 2 replies; 26+ messages in thread From: Mimi Zohar @ 2018-12-30 3:33 UTC (permalink / raw) To: Michael Niewöhner, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-30 3:33 ` Mimi Zohar @ 2018-12-30 13:22 ` Michael Niewöhner 2018-12-31 18:10 ` Ken Goldman 2018-12-31 21:17 ` Mimi Zohar 2018-12-31 17:56 ` Ken Goldman 1 sibling, 2 replies; 26+ messages in thread From: Michael Niewöhner @ 2018-12-30 13:22 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-30 13:22 ` Michael Niewöhner @ 2018-12-31 18:10 ` Ken Goldman 2018-12-31 21:17 ` Mimi Zohar 1 sibling, 0 replies; 26+ messages in thread From: Ken Goldman @ 2018-12-31 18:10 UTC (permalink / raw) To: Michael Niewöhner, linux-integrity, linux-kernel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-30 13:22 ` Michael Niewöhner 2018-12-31 18:10 ` Ken Goldman @ 2018-12-31 21:17 ` Mimi Zohar 2019-01-01 16:15 ` Michael Niewöhner 1 sibling, 1 reply; 26+ messages in thread From: Mimi Zohar @ 2018-12-31 21:17 UTC (permalink / raw) To: Michael Niewöhner, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-31 21:17 ` Mimi Zohar @ 2019-01-01 16:15 ` Michael Niewöhner 2019-01-01 16:38 ` Mimi Zohar 0 siblings, 1 reply; 26+ messages in thread From: Michael Niewöhner @ 2019-01-01 16:15 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-01 16:15 ` Michael Niewöhner @ 2019-01-01 16:38 ` Mimi Zohar 2019-01-01 16:47 ` Michael Niewöhner 0 siblings, 1 reply; 26+ messages in thread From: Mimi Zohar @ 2019-01-01 16:38 UTC (permalink / raw) To: Michael Niewöhner, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-01 16:38 ` Mimi Zohar @ 2019-01-01 16:47 ` Michael Niewöhner 0 siblings, 0 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-01 16:47 UTC (permalink / raw) To: Mimi Zohar, Jarkko Sakkinen, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-30 3:33 ` Mimi Zohar 2018-12-30 13:22 ` Michael Niewöhner @ 2018-12-31 17:56 ` Ken Goldman 1 sibling, 0 replies; 26+ messages in thread From: Ken Goldman @ 2018-12-31 17:56 UTC (permalink / raw) To: Mimi Zohar, linux-integrity, linux-kernel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-23 11:55 ` Michael Niewöhner 2018-12-25 13:55 ` Michael Niewöhner @ 2019-01-03 13:27 ` Jarkko Sakkinen 2019-01-03 13:38 ` Michael Niewöhner 1 sibling, 1 reply; 26+ messages in thread From: Jarkko Sakkinen @ 2019-01-03 13:27 UTC (permalink / raw) To: Michael Niewöhner Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 13:27 ` Jarkko Sakkinen @ 2019-01-03 13:38 ` Michael Niewöhner 2019-01-03 15:04 ` Jarkko Sakkinen 0 siblings, 1 reply; 26+ messages in thread From: Michael Niewöhner @ 2019-01-03 13:38 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 13:38 ` Michael Niewöhner @ 2019-01-03 15:04 ` Jarkko Sakkinen 2019-01-03 15:47 ` Michael Niewöhner 0 siblings, 1 reply; 26+ messages in thread From: Jarkko Sakkinen @ 2019-01-03 15:04 UTC (permalink / raw) To: Michael Niewöhner Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 15:04 ` Jarkko Sakkinen @ 2019-01-03 15:47 ` Michael Niewöhner 2019-01-04 11:58 ` Michael Niewöhner 2019-01-10 17:19 ` Jarkko Sakkinen 0 siblings, 2 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-03 15:47 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 15:47 ` Michael Niewöhner @ 2019-01-04 11:58 ` Michael Niewöhner 2019-01-04 15:28 ` Michael Niewöhner 2019-01-10 17:19 ` Jarkko Sakkinen 1 sibling, 1 reply; 26+ messages in thread From: Michael Niewöhner @ 2019-01-04 11:58 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-04 11:58 ` Michael Niewöhner @ 2019-01-04 15:28 ` Michael Niewöhner 2019-01-04 18:26 ` Michael Niewöhner 2019-01-10 17:28 ` Jarkko Sakkinen 0 siblings, 2 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-04 15:28 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-04 15:28 ` Michael Niewöhner @ 2019-01-04 18:26 ` Michael Niewöhner 2019-01-10 17:28 ` Jarkko Sakkinen 1 sibling, 0 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-04 18:26 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-04 15:28 ` Michael Niewöhner 2019-01-04 18:26 ` Michael Niewöhner @ 2019-01-10 17:28 ` Jarkko Sakkinen 2019-01-10 18:03 ` Michael Niewöhner 1 sibling, 1 reply; 26+ messages in thread From: Jarkko Sakkinen @ 2019-01-10 17:28 UTC (permalink / raw) To: Michael Niewöhner Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-10 17:28 ` Jarkko Sakkinen @ 2019-01-10 18:03 ` Michael Niewöhner 0 siblings, 0 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-10 18:03 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 15:47 ` Michael Niewöhner 2019-01-04 11:58 ` Michael Niewöhner @ 2019-01-10 17:19 ` Jarkko Sakkinen 2019-01-10 18:00 ` Michael Niewöhner 1 sibling, 1 reply; 26+ messages in thread From: Jarkko Sakkinen @ 2019-01-10 17:19 UTC (permalink / raw) To: Michael Niewöhner Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-10 17:19 ` Jarkko Sakkinen @ 2019-01-10 18:00 ` Michael Niewöhner 0 siblings, 0 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-10 18:00 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2018-12-16 13:32 tpm_tis TPM2.0 not detected on cold boot Michael Niewöhner 2018-12-22 13:47 ` Michael Niewöhner @ 2019-01-03 13:41 ` Jarkko Sakkinen 2019-01-03 13:55 ` Michael Niewöhner 1 sibling, 1 reply; 26+ messages in thread From: Jarkko Sakkinen @ 2019-01-03 13:41 UTC (permalink / raw) To: Michael Niewöhner Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: tpm_tis TPM2.0 not detected on cold boot 2019-01-03 13:41 ` Jarkko Sakkinen @ 2019-01-03 13:55 ` Michael Niewöhner 0 siblings, 0 replies; 26+ messages in thread From: Michael Niewöhner @ 2019-01-03 13:55 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Mimi Zohar, James Bottomley, peterhuewe, jgg, arnd, linux-integrity, linux-kernel, Nayna Jain, Ken Goldman 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-01-10 18:03 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-16 13:32 tpm_tis TPM2.0 not detected on cold boot Michael Niewöhner 2018-12-22 13:47 ` Michael Niewöhner 2018-12-22 22:53 ` Mimi Zohar 2018-12-23 11:55 ` Michael Niewöhner 2018-12-25 13:55 ` Michael Niewöhner 2018-12-30 3:33 ` Mimi Zohar 2018-12-30 13:22 ` Michael Niewöhner 2018-12-31 18:10 ` Ken Goldman 2018-12-31 21:17 ` Mimi Zohar 2019-01-01 16:15 ` Michael Niewöhner 2019-01-01 16:38 ` Mimi Zohar 2019-01-01 16:47 ` Michael Niewöhner 2018-12-31 17:56 ` Ken Goldman 2019-01-03 13:27 ` Jarkko Sakkinen 2019-01-03 13:38 ` Michael Niewöhner 2019-01-03 15:04 ` Jarkko Sakkinen 2019-01-03 15:47 ` Michael Niewöhner 2019-01-04 11:58 ` Michael Niewöhner 2019-01-04 15:28 ` Michael Niewöhner 2019-01-04 18:26 ` Michael Niewöhner 2019-01-10 17:28 ` Jarkko Sakkinen 2019-01-10 18:03 ` Michael Niewöhner 2019-01-10 17:19 ` Jarkko Sakkinen 2019-01-10 18:00 ` Michael Niewöhner 2019-01-03 13:41 ` Jarkko Sakkinen 2019-01-03 13:55 ` Michael Niewöhner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).