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

[Roberto Sassu]

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).

+ Jarkko

Hi Nicolai

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?

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.

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).

Roberto

> Many thanks!
> 
> Nicolai
> 
> [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
> 
> Nicolai Stange (7):
>   ima: don't expose runtime_measurements for unsupported hashes
>   ima: always create runtime_measurements sysfs file for ima_hash
>   ima: move INVALID_PCR() to ima.h
>   ima: track the set of PCRs ever extended
>   tpm: enable bank selection for PCR extend
>   ima: invalidate unsupported PCR banks once at first use
>   ima: make SHA1 non-mandatory
> 
>  drivers/char/tpm/tpm-interface.c      | 29 +++++++++-
>  drivers/char/tpm/tpm.h                |  3 +-
>  drivers/char/tpm/tpm2-cmd.c           | 29 +++++++++-
>  include/linux/tpm.h                   |  3 +
>  security/integrity/ima/Kconfig        | 14 +++++
>  security/integrity/ima/ima.h          |  9 +++
>  security/integrity/ima/ima_crypto.c   | 83 ++++++++++++++++-----------
>  security/integrity/ima/ima_fs.c       | 41 +++++++------
>  security/integrity/ima/ima_policy.c   |  5 +-
>  security/integrity/ima/ima_queue.c    | 26 ++++++++-
>  security/integrity/ima/ima_template.c |  7 +++
>  11 files changed, 190 insertions(+), 59 deletions(-)
>