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? Thanks Roberto > Thanks, > Jashan > > > On 27 Aug 2026, at 6:47 PM, Roberto Sassu <[email protected]> > > wrote: > > > > On Wed, 2026-08-26 at 19:14 -0400, Mimi Zohar wrote: > > > Hi Jashan, > > > > > > Mail to the kernel mailing lists are in plain text. Please refer to > > > https://docs.kernel.org/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text > > > > > > > > > On Wed, 2026-08-26 at 22:35 +0000, Singh, Jashandeep wrote: > > > > Thanks Mimi. > > > > > > > > > > > > Agreed that all allocated banks are extended via tpm_pcr_extend() - but > > > > that's > > > > the PCR-extend (write) path. The failure is in > > > > ima_calc_boot_aggregate(), which > > > > reads PCRs 0-9 from a *single* selected bank. > > > > > > > > > > > > The issue is that a TPM can be provisioned with *only* the SHA-384 bank > > > > enabled, > > > > while the default IMA hash algorithm is SHA-256. In this configuration, > > > > the > > > > current selection logic only matches the configured IMA default, then > > > > SHA-256, > > > > and then SHA-1 - it never considers SHA-384. > > > > > > It's walking the list of allocated TPM banks and, if allocated, sets > > > bank_idx. > > > > > > for (i = 0; i < ima_tpm_chip->nr_allocated_banks; i++) { > > > crypto_id = ima_tpm_chip->allocated_banks[i].crypto_id; > > > if (crypto_id == hash->algo) { > > > bank_idx = i; > > > break; > > > } > > > > > > The question is why isn't the sha384 bank found in the list of > > > nr_allocated_banks? > > > > The boot aggregate algorithm is the same as the default hash algorithm. > > > > Please try ima_hash=sha384. > > > > Thanks > > > > Roberto > > > > > Mimi > > > > > > > > > > > Adding a SHA-384 match allows the boot aggregate to be computed > > > > correctly > > > > (sha384:...) instead of returning 0 and logging "No suitable TPM > > > > algorithm for > > > > boot aggregate". The fact that the SHA-384 bank can be selected and the > > > > boot > > > > aggregate computed also confirms that the SHA-384 bank is recognized and > > > > allocated, rather than being missing. > >
