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.
