Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> 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)
