Re: [RFC PATCH v1 0/7] ima: get rid of hard dependency on SHA-1

[Nicolai Stange <nstange@suse.de>]

Roberto Sassu <roberto.sassu@huaweicloud.com> writes:

> On Thu, 2025-03-13 at 18:33 +0100, Nicolai Stange wrote:
>> Hi all,
>> 
>> if no SHA-1 implementation was available to the kernel, IMA init would
>> currently fail, rendering the whole subsystem unusable.
>> 
>> This patch series is an attempt to make SHA-1 availability non-mandatory
>> for IMA. The main motivation is that NIST announced to sunset SHA-1 by
>> 2030 ([1]), whereby any attempt to instantiate it when booted in FIPS mode
>> would have to be made to fail with -ENOENT. As this does potentially have
>> an impact on lifetimes for FIPS certifications issued today, distros might
>> be interested in disabling SHA-1 downstream soon already.
>> 
>> Anyway, making IMA to work without a SHA-1 implementation available is not
>> so straightforward, mainly due to that established scheme to substitute
>> padded SHA-1 template hashes for PCR banks with unmapped/unavailable algos.
>> There is some userspace around expecting that existing behavior, e.g. the
>> ima_measurement command from ([2]), and breaking that in certain scenarios
>> is inevitable.
>> 
>> I tried to make it the least painful possible, and I think I arrived at
>> a not completely unreasonable solution in the end, but wouldn't be too
>> surprised if you had a different stance on that. So I would be curious
>> about your feedback on whether this is a route worth pursuing any further.
>> FWIW, the most controversial parts are probably
>>  - [1/7] ima: don't expose runtime_measurements for unsupported hashes
>>  - [6/7] ima: invalidate unsupported PCR banks once at first use
>> 
>> Note that I haven't tested this series thoroughly yet -- for the time being
>> I only ran a couple of brief smoke tests in a VM w/o a TPM  (w/ and w/o
>> SHA-1 disabled of course).
>

Hi Roberto,

> thanks a lot for the patches. Still didn't go through them, but if I
> understood correctly you assume that the SHA1 PCR bank would be still
> seen by IMA.
>
> In light of deprecation of SHA1, is this assumption correct?

yes, the assumption made here is that a SHA-1 TPM bank might exist and
is visible to IMA, but that the kernel would not have a working SHA-1
implementation available.

>
> I would expect that TPM manufacturers or even the TPM driver would
> change to fullfill that.
>
> I guess the first stage would be making sure that the SHA1 PCR bank is
> unusable at the TPM driver level. A first thought would be to extend
> the SHA1 PCR bank with a random value at boot (or earlier), so that the
> remote attestation would never work on that PCR bank. At that point, I
> would probably go further and not expose the SHA1 PCR bank at all, so
> you would have less problems on IMA side.

I would like to note in this context that from my POV there's nothing
really special about SHA-1 when compared to any other potential TPM bank
hash algos the kernel doesn't have an implementation for. That is, if a
TPM implemented say SHA3-256 and the kernel did not have an
implementation of that built-in, it would be a very similar situation as
far as IMA is concerned, i.e. it would have to get handled somehow.

Thanks!

Nicolai

>
> The second stage would probably be that the TPM firmware would be
> updated, not allowing the SHA1 PCR bank to be allocated.
>
> Other than that, sure, also actions need to be done to remove SHA1
> support in IMA (will look at your patches).
>
>> 
>> [1] https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
>> [2] https://github.com/linux-integrity/ima-evm-utils.git
>> 

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)