Thanks, Mimi and Roberto. I will explore this approach and share the updated patch.
Regards, Jashan > On 27 Aug 2026, at 9:19 PM, Mimi Zohar <[email protected]> wrote: > > On Thu, 2026-08-27 at 16:56 +0200, Roberto Sassu wrote: >> On Thu, 2026-08-27 at 14:46 +0000, Singh, Jashandeep wrote: >>> Mimi, the patch covers the case where the TPM is provisioned with a single >>> PCR >>> bank, SHA-384, while the default IMA hash is configured as SHA-256. >>> >>> The SHA-384 bank is present in nr_allocated_banks, but it matches neither >>> the >>> configured default (SHA-256) nor the current hardcoded fallbacks (SHA-256, >>> then >>> SHA-1). As a result, bank_idx remains -1, and we hit "No suitable TPM >>> algorithm >>> for boot aggregate", leaving the boot aggregate zeroed. >>> >>> Roberto, it is not strictly true that the boot aggregate algorithm is >>> always the >>> same as the default IMA hash algorithm. >>> >>> When the bank corresponding to the default hash is not allocated, the >>> existing >>> SHA-256/SHA-1 fallback logic selects a different bank than the default. >>> Therefore, the boot aggregate can already use a different algorithm from the >>> configured IMA hash. >>> >>> My patch adds SHA-384 as one more fallback for the case where SHA-384 is the >>> only allocated bank. This allows users with such a configuration to have the >>> boot aggregate computed, without requiring them to change their default IMA >>> hash to SHA-384. >> >> That would work for your use case, but what about anyone using a single >> SHA-512 PCR bank? >> >> Would it be fine to add a new Kconfig and kernel option to specify a >> custom boot aggregate algorithm? > > Yes, I'm fine with defining a new Kconfig and kernel option. > > Examples: > sha384: <digest> boot_aggregate, where the digest is calculated based on the > TPM > 384 bank PCRs. > > sha512: <digest> boot_aggregate, where the digest is calculated based on the > TPM > 512 bank PCRs. > > Mimi
