Bugzilla – Bug 1185869
TPM event log is empty
Last modified: 2021-05-18 08:23:41 UTC
# uname -a Linux dhcp175 5.12.0-2-default #1 SMP Thu Apr 29 12:08:56 UTC 2021 (c4830af) x86_64 x86_64 x86_64 GNU/Linux In TW's kernel the TPM 2.0 event log seems empty. * UEFI and secure boot are enabled. # mokutil --sb-state SecureBoot enabled * TPM is active and recognized # dmesg | grep -i tpm [ 0.000000] efi: TPMFinalLog=0x7fbd7000 SMBIOS=0x7f90a000 ACPI=0x7fb7e000 ACPI 2.0=0x7fb7e014 MEMATTR=0x7e7ee018 MOKvar=0x7e214000 TPMEventLog=0x7e1ec018 [ 0.005013] ACPI: TPM2 0x000000007FB78000 00004C (v04 BOCHS BXPC 00000001 BXPC 00000001) [ 0.005025] ACPI: Reserving TPM2 table memory at [mem 0x7fb78000-0x7fb7804b] * The kernel device is present # ls /dev/tpm* /dev/tpm0 /dev/tpmrm0 * The PCRs are available # cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00/tpm/tpm0/pcr-sha1/1 E5824C8CFF29C5C0B3F93F51C9E0F5E895B9C463 * The event log is not transmitted from EFI / GRUB to the kernel # tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements --- events: ERROR: failed to parse tpm2 eventlog ERROR: Unable to run tpm2_eventlog (a simple `cat /sys/kernel/security/tpm0/binary_bios_measurements` shows that is indeed empty) * Some kernel config that I see: CONFIG_TCG_TPM=y CONFIG_HW_RANDOM_TPM=y CONFIG_TCG_VTPM_PROXY=m CONFIG_DTPM=y CONFIG_DTPM_CPU=y CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m CONFIG_TPM_KEY_PARSER=m In comparison, I installed Ubuntu 20.04 LTS using the same emulation stack (QEMU + swtpm), and the event log is present with information. # uname -a Linux tpmtest 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Both VMs are available for inspection.
I can reproduce the bug with an older Tumbleweed with kernel 5.10.7. Meanwhile, I also found an patch for tpm2-tools: https://github.com/tpm2-software/tpm2-tools/commit/10b8344d320830af346557bfde9ffb8a918bbbd8 Will try the patch first.
(In reply to Gary Ching-Pang Lin from comment #1) > I can reproduce the bug with an older Tumbleweed with kernel 5.10.7. > > Meanwhile, I also found an patch for tpm2-tools: > https://github.com/tpm2-software/tpm2-tools/commit/ > 10b8344d320830af346557bfde9ffb8a918bbbd8 > > Will try the patch first. The patch is included in tpm2-tools 5.0 already in tw. But I think that the issue is different. This patch is about that the kernel report (correctly) a size 0 for the event log, but the workaround is a matter or cp it to a different place. This will create a file with size and content. Also you can cat the event log to see the same content. The reported bug is that the event log is indeed empty. So the cp or cat do not shows any information. Also thanks for checking this!!
(In reply to Alberto Planas Dominguez from comment #2) > (In reply to Gary Ching-Pang Lin from comment #1) > > I can reproduce the bug with an older Tumbleweed with kernel 5.10.7. > > > > Meanwhile, I also found an patch for tpm2-tools: > > https://github.com/tpm2-software/tpm2-tools/commit/ > > 10b8344d320830af346557bfde9ffb8a918bbbd8 > > > > Will try the patch first. > > The patch is included in tpm2-tools 5.0 already in tw. But I think that the > issue is different. This patch is about that the kernel report (correctly) a > size 0 for the event log, but the workaround is a matter or cp it to a > different place. This will create a file with size and content. Also you can > cat the event log to see the same content. > Ya, I just found that the fix is already merged. > The reported bug is that the event log is indeed empty. So the cp or cat do > not shows any information. > Indeed, it somehow became empty. It seems to me that kernel successfully detected TPM from ACPI or EFI, or binary_bios_measurements won't be created. However, it got nothing in the end. Have to dig more. > Also thanks for checking this!!
Hmmm, the edk2 upstream actually discussed the issue weeks ago: https://www.mail-archive.com/devel@edk2.groups.io/msg30443.html The fix was identified: https://www.mail-archive.com/devel@edk2.groups.io/msg30605.html https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3dcd15665aca80197333500a4be3900948afccc1 I checked the stable tree for linux 5.12.y and the fix wasn't picked into 5.12.2, so it currently only exists in the unreleased 5.13 tree.
(In reply to Gary Ching-Pang Lin from comment #4) > Hmmm, the edk2 upstream actually discussed the issue weeks ago: > https://www.mail-archive.com/devel@edk2.groups.io/msg30443.html > > The fix was identified: > https://www.mail-archive.com/devel@edk2.groups.io/msg30605.html > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=3dcd15665aca80197333500a4be3900948afccc1 > > I checked the stable tree for linux 5.12.y and the fix wasn't picked into > 5.12.2, so it currently only exists in the unreleased 5.13 tree. Good catch. Seems that kernel:HEAD[1] is using 5.12. Do makes sense to backport the patch, or is better to wait? [1] https://build.opensuse.org/package/show/Kernel:HEAD/kernel-default
(In reply to Alberto Planas Dominguez from comment #5) > (In reply to Gary Ching-Pang Lin from comment #4) > > Hmmm, the edk2 upstream actually discussed the issue weeks ago: > > https://www.mail-archive.com/devel@edk2.groups.io/msg30443.html > > > > The fix was identified: > > https://www.mail-archive.com/devel@edk2.groups.io/msg30605.html > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > > ?id=3dcd15665aca80197333500a4be3900948afccc1 > > > > I checked the stable tree for linux 5.12.y and the fix wasn't picked into > > 5.12.2, so it currently only exists in the unreleased 5.13 tree. > > Good catch. Seems that kernel:HEAD[1] is using 5.12. Do makes sense to > backport the patch, or is better to wait? > > [1] https://build.opensuse.org/package/show/Kernel:HEAD/kernel-default We usually don't proactively backport patches to kernel:HEAD or kernel:stable unless it's urgent security fixes. The stable ML is CC'ed in the kernel fix. If you can wait, I believe it'd be in the stable tree soon.
(In reply to Gary Ching-Pang Lin from comment #6) > We usually don't proactively backport patches to kernel:HEAD or > kernel:stable unless it's urgent security fixes. The stable ML is CC'ed in > the kernel fix. If you can wait, I believe it'd be in the stable tree soon. Sure, this can wait. I will try to confirm that the patch indeed resolves the issue. Thanks!
I got some bugs that need to backport fixes into the kernel master so I'll take this fix along with other fixes.
(In reply to Gary Ching-Pang Lin from comment #8) > I got some bugs that need to backport fixes into the kernel master so I'll > take this fix along with other fixes. During the backporting, I found that the target patch is already merged into 5.12.3. Let's wait for 5.12.3.
(In reply to Gary Ching-Pang Lin from comment #9) > During the backporting, I found that the target patch is already merged into > 5.12.3. Let's wait for 5.12.3. This is good news!
Updated and now the event log provides information: dhcp172:~ # tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements --- events: - EventNum: 0 PCRIndex: 0 EventType: EV_NO_ACTION Digest: "0000000000000000000000000000000000000000" EventSize: 37 ... Thanks!!