From: Lennart Poettering <lennart@amutable.com>
Date: Sat, 20 Jun 2026 13:16:17 +0000 (+0200)
Subject: tpm2: support SHA384/SHA512 PCR banks in tpm2_get_best_pcr_bank() (#42538)
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cbe3a9ff1127e20695fb8c189259745c077121e9;p=thirdparty%2Fsystemd.git

tpm2: support SHA384/SHA512 PCR banks in tpm2_get_best_pcr_bank() (#42538)

`tpm2_get_best_pcr_bank()` only ever considered the SHA256 and SHA1
banks (both the `LoaderTpm2ActivePcrBanks` path and the capability
guesswork). On a TPM whose only active bank is SHA384 it returned
`-EOPNOTSUPP`, breaking sealing/enrollment (cryptenroll, credential
encryption, legacy unseal). The restriction looks like a historical
simplification — `efi_get_active_pcr_banks()` already decodes
SHA384/SHA512 and `tpm2_hash_algorithms[]` already lists them.

This PR introduces an explicit preference table (SHA256 > SHA512 >
SHA384 > SHA1) and selects from it. SHA256 stays the top preference for
backwards compatibility, so existing systems keep using the same bank
and the legacy unseal-guess in `tpm2_unseal()` stays consistent;
SHA384/SHA512 are only chosen when SHA256 is unavailable, SHA1 remains
the last resort.

Behavior for existing SHA256/SHA1 systems is unchanged. Includes a unit
test for the bank-preference logic.

Related to https://github.com/systemd/systemd/pull/42537
---

cbe3a9ff1127e20695fb8c189259745c077121e9