I’m using the AMD 7840U version of the Framework 13 with bios 3.05, and I’m having problems reading the TPM Event Log (/sys/firmware/acpi/tables/TPM2 or /sys/kernel/security/tpm0/binary_bios_measurements). This has been reported before, but I could not find any resolution of the issue. I’ve tried with Qubes 4.2 (kernel 6.6.54-1) and with arch Linux live USB. Both give an ACPI table where the addresses are null pointers.
Can anyone with an AMD laptop running Linux see (and read) the binary_bios_measurements file? I’ve spent way too long on this issue, and I need a sanity check from someone.
This is starting to look like a firmware issue. Am I correct in assuming that you see a similar (very short) output from sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements?
Kernel 6.12.0 gives output that has lots of lines from:
00000000:
to
0000d750:
With regards to the contents, it looks a lot like content grub might have put in there. So not necessarily populated by the BIOS.
I have Ubuntu 24.04. Mainline kernel 6.12.0 (compiled my me)
with ubuntu kernel: 6.8.0-49-generic
gives output that has lots of lines from:
00000000:
to
0000fd70:
Wow… you completely broke my theory of what’s going on… thank you.
My understanding was that if the ACPI table TPM2 exists, then it loads the table based on the two pointers at the end of that file, even if they are null pointers. If the table does not exist, it instead reads the event log from EFI instead. I though my issue was that my last two pointers were all zeroes, but my ACPI/TPM2 table is identical to yours… Could you please let me know which distro and kernel version you are running? Never mind, I just noticed that you included that information above.
Nov 23 16:39:35 dom0 kernel: efi: ACPI=0x5affe000 ACPI 2.0=0x5affe014 TPMFinalLog=0x5af3f000 SMBIOS=0x58e77000 SMBIOS 3.0=0x58e74000 (MEMATTR=0x52f4d018 unusable) ESRT=0x5af95018
Nov 23 16:39:35 dom0 kernel: ACPI: TPM2 0x000000005AFE9000 000050 (v05 INSYDE EDK2 20505348 ACPI 00040000)
Nov 23 16:39:35 dom0 kernel: ACPI: Reserving TPM2 table memory at [mem 0x5afe9000-0x5afe904f]
Nov 23 16:39:35 dom0 systemd[1]: systemd 251.19-1.fc37 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Nov 23 16:39:35 dom0 systemd-sysusers[282]: Creating user 'tss' (Account used for TPM access) with UID 59 and GID 59.
Nov 23 16:40:00 dom0 systemd[1]: systemd 251.19-1.fc37 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
On my efi: line I list the address for TPMFinalLog, but I miss a lot of addresses you have, probably most importantly TPMEventLog. Now I have to figure out where this data comes from. I got TPMEventLog when I ran Ubuntu Live, but by table was a single post there.
Just to verify that your event log isn’t only grub, could you check if your sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements includes events on PCR4? It is set before grub is even loaded.
I think you are on to something with the difference in “efi:” line.
The “(MEMATTR=0x52f4d018 unusable)” seems to be the problem with your laptop.
The “unusable” bit is the difference between yours and mine.
Right, thanks for pointing that out. I noticed that earlier, but not in regards to the TPM stuff, so I think I got blind to it. I’ll take a look at that.
edit: Absolutely, help is very appreciated, I feel like I’m in deep water. Apparently I’m too new user to post more… hopefully you see this, I’m on 13 hour timeout. xen dmesg dom0 dmesg
edit 2: Thank you very much for all the effort! What you’re seeing doesn’t require Secure Boot, it’s part of a (in my opinion) more secure alternative to Secure Boot called Measured Boot. It can be used to tell the TPM to only provide a secret in the case where a precondition is met. For example, register 4 is a hash of the firmware and all loaded efi files, so you can tell the TPM to provide a secret only if the hash matches a preset hash, meaning that you know that no other software (such as rootkits) are running. That way, you can even dual boot without risking infection from the other partition OS (provided you can trust your firmware and TPM), since the rootkit would have to infect the encrypted disk. This does require that you include everything in the hash, though, including grub and initramfs, but if you can get it running on a unified kernel image then you’re all set.
Looking at your dmesg output and comparing it to mine.
I cannot find anything obviously wrong.
I don’t know if this helps you, but this is the section of kernel code that marks it as unusable:
drivers/firmware/efi/efi.c:637
static __init int match_config_table(const efi_guid_t *guid,
unsigned long table,
const efi_config_table_type_t *table_types)
{
int i;
for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) {
if (efi_guidcmp(*guid, table_types[i].guid))
continue;
if (!efi_config_table_is_usable(guid, table)) {
if (table_types[i].name[0])
pr_cont("(%s=0x%lx unusable) ",
table_types[i].name, table);
return 1;
}
*(table_types[i].ptr) = table;
if (table_types[i].name[0])
pr_cont("%s=0x%lx ", table_types[i].name, table);
return 1;
}
return 0;
}
An interesting part of that is this:
static inline
bool efi_config_table_is_usable(const efi_guid_t *guid, unsigned long table)
{
if (!IS_ENABLED(CONFIG_XEN_EFI))
return true;
return xen_efi_config_table_is_usable(guid, table);
}
The different path through the code is used if you are using a CONFIG_XEN_EFI kernel.
Summary:
Non XEN kernels are OK.
XEN kernels have the problem.
In my tpm event log I have the initial “EV_NO_ACTION” “Spec ID Event03”, then 47 events of “Unknown event type” with EventSize 16, and then some interesting ones:
and then about 25 more interesting events, with “Exit Boot Services” at the end. And btw I don’t have secure-boot enabled
My shot-in-the-dark guess would be, some combination of options in the bios/firmware, has tickled some bugs in there. Maybe try resetting bios/UEFI settings to defaults, and check in the secure-boot options too …
