Commit Graph
2 Commits
Author SHA1 Message Date
Luca Boccassi 9a725391f1 commands/efi/tpm: Call get_active_pcr_banks() only with TCG2 1.1 or newer
The call was added in the 1.1 revision of the spec, 1.0 does
not have it, and there are some machines out there with a TPM2
and a UEFI firmware that only supports version 1.0, so the
call fails in those cases. Check the reported version before
calling get_active_pcr_banks().

See Table 4 in section 6.2 of the TCG EFI Protocol Specification:

  https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf

Fixes: f326c5c47 (commands/bli: Set LoaderTpm2ActivePcrBanks runtime variable)

Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Reviewed-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2025-10-11 15:36:54 +02:00
Luca Boccassi f326c5c475 commands/bli: Set LoaderTpm2ActivePcrBanks runtime variable
It turns out checking from userspace is not 100% reliable to figure out
whether the firmware had TPM2 support enabled or not. For example with
EDK2 arm64, the default upstream build config bundles TPM2 support with
SecureBoot support, so if the latter is disabled, TPM2 is also unavailable.
But still, the ACPI TPM2 table is created just as if it was enabled. So,
/sys/firmware/acpi/tables/TPM2 exists and looks correct but there are no
measurements, neither the firmware nor the loader/stub can do them, and
/sys/kernel/security/tpm0/binary_bios_measurements does not exist.
So, userspace cannot really tell what was going on in UEFI mode.

The loader can use the apposite UEFI protocol to check, which is a more
definitive answer. Export the bitmask with the list of active banks as-is.
If it's not 0, then in userspace we can be sure a working TPM2 was available
in UEFI mode.

systemd-boot and systemd-stub v258 (current main) set this variable and
userspace portion consumes it to be able to tell what was available in
the firmware context.

Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2025-08-14 21:20:01 +02:00