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

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

[Singh, Jashandeep]

From: Jashandeep Singh <jdsw@juniper.net>

ima_calc_boot_aggregate() selects a TPM PCR bank matching the
configured IMA hash algorithm, otherwise falling back to the SHA256
bank or the SHA1 bank.

A TPM 2.0 can be provisioned with only the SHA384 bank enabled, with no
SHA256 or SHA1 bank. None of the above then matched, selection failed
with

    ima: No suitable TPM algorithm for boot aggregate

and the boot aggregate digest was left as zeros, as for TPM bypass,
making remote attestation impossible.

Accept the SHA384 bank as a fallback. The configured IMA hash algorithm
is still matched first.

Signed-off-by: Jashandeep Singh <jdsw@juniper.net>
---
 security/integrity/ima/ima_crypto.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0d72b48249ee..c7a60b438955 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -491,7 +491,8 @@ int ima_calc_boot_aggregate(struct ima_digest_data *hash)
 			break;
 		}
 
-		if (crypto_id == HASH_ALGO_SHA256)
+		if (crypto_id == HASH_ALGO_SHA256 ||
+		    crypto_id == HASH_ALGO_SHA384)
 			bank_idx = i;
 
 		if (bank_idx == -1 && crypto_id == HASH_ALGO_SHA1)
-- 
2.34.1

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

[Mimi Zohar]

On Wed, 2026-08-26 at 19:11 +0000, Singh, Jashandeep wrote:
> From: Jashandeep Singh <jdsw@juniper.net>
> 
> ima_calc_boot_aggregate() selects a TPM PCR bank matching the
> configured IMA hash algorithm, otherwise falling back to the SHA256
> bank or the SHA1 bank.
> 
> A TPM 2.0 can be provisioned with only the SHA384 bank enabled, with no
> SHA256 or SHA1 bank. None of the above then matched, selection failed
> with
> 
>     ima: No suitable TPM algorithm for boot aggregate
> 
> and the boot aggregate digest was left as zeros, as for TPM bypass,
> making remote attestation impossible.
> 
> Accept the SHA384 bank as a fallback. The configured IMA hash algorithm
> is still matched first.

FYI, all enabled TPM banks are extended.  Refer to the functions
ima_pcr_extend() and tpm_pcr_extend().

The IMA measurement list contains file data hashes based on the IMA default hash
algorithm.  Similarly, the boot_aggregate hash is calculated using the IMA
default hash algorithm.

If you're seeing "ima: No suitable TPM algorithm for boot aggregate", it
probably means no TPM banks are configured.

Mimi
 

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

[Mimi Zohar]

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?

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.

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

[Roberto Sassu]

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.

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

[Singh, Jashandeep]

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.

Thanks,
Jashan

> On 27 Aug 2026, at 6:47 PM, Roberto Sassu <roberto.sassu@huaweicloud.com> 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.

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

[Roberto Sassu]

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 <roberto.sassu@huaweicloud.com> 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.
> 
> 

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

[Mimi Zohar]

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
> 

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

[Singh, Jashandeep]

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 <zohar@linux.ibm.com> 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