Re: [PATCH] ima: select the SHA384 PCR bank for the boot aggregate

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.