Re: 6.17 Regression: loading trusted.ko with fips=1 fails due to crypto/testmgr.c: desupport SHA-1 for FIPS 140

[Eric Biggers <ebiggers@kernel.org>]

On Sat, Oct 04, 2025 at 02:58:43PM +0000, Jon Kohler wrote:
> 
> 
> > On Oct 4, 2025, at 2:43 AM, Vegard Nossum <vegard.nossum@oracle.com> wrote:
> > 
> > !-------------------------------------------------------------------|
> > CAUTION: External Email
> > 
> > |-------------------------------------------------------------------!
> > 
> > On 04/10/2025 05:00, Jon Kohler wrote:
> >> Hello crypto list,
> >> Working through testing 6.17 on our platform, which uses fips=1, and
> >> noticed that we’re having trouble modprobe dm_crypt, where dmesg barks
> >> with the following entries:
> >> [18993.394808] trusted_key: could not allocate crypto hmac(sha1)
> >> [18993.479942] device-mapper: table: 254:6: crypt: unknown target type
> >> [18993.482967] device-mapper: ioctl: error adding target to table
> >> Looking at modprobe dm_crypt with strace, it looks to be trying to
> >> load trusted.ko first, and indeed when doing 'modprobe trusted', we
> >> see the same log entries from trusted_key over and over again.
> >> The test case on our side that hit this is a trivial sanity case, where
> >> a userspace app tries to do the following on a throw away volume:
> >>   cryptsetup open --type plain --cipher aes-xts-plain64 \
> >>                   --key-file /dev/urandom /dev/sdXXX sdXXX_crypt
> >> This user space cryptsetup call fails, and we then see the dmesg logs
> >> as noted.
> >> We compile CONFIG_TRUSTED_KEYS && CONFIG_TRUSTED_KEYS_TPM, and it looks
> >> like we're hitting trusted_tpm1.c's hmac_alg[] = "hmac(sha1)".
> >> In my tree, I reverted this patch [1] and modprobe dm-crypt is happy
> >> again, and the cryptsetup-based test case passes now.
> >> I'm scratching my head as to the right thing to do here, as on one hand
> >> I agree with the patch notion that we want to start the deprecation
> >> cycle for SHA1, but on the other hand, if CONFIG_TRUSTED_KEYS_TPM is
> >> enabled, we're going to run straight into this all the time as it
> >> doesn't look like theres a way to override this to use some higher algo
> >> Happy to discuss and try out ideas.
> >> Thanks,
> >> Jon
> >> [1] 9d50a25eeb0 ("crypto/testmgr.c: desupport SHA-1 for FIPS 140") and
> > 
> > Hi,
> > 
> > Thanks for the report.
> > 
> > I think this patch addresses the issue you're seeing:
> > 
> > https://lore.kernel.org/all/20250904155216.460962-7-vegard.nossum@oracle.com/
> > (In short, it's not that we really need to use sha1, it just means the
> > hardware isn't available for use with those boot parameters.)
> 
> Thanks for the pointer! I tested this out just now, and with the original desupport
> patch + this one, trusted.ko/dm-crypt work just fine and the cryptsetup test
> case now passes.
> 
> In general, this seems like a good patch. 
> 
> Could we pull this out of the RFC and apply it as a Fixes for this issue perhaps?
> 
> > There was also a more recent discussion around the patch here:
> > 
> > https://lore.kernel.org/all/f31dbb22-0add-481c-aee0-e337a7731f8e@oracle.com/
> > I'm guessing the sha1 deprecation commit should be reverted if it wasn't
> > already. Maybe we should just add a big deprecation warning during boot
> > if sha1 is used with fips=1 until 2030?
> 
> You know how deprecation warnings go. Largely ignored, then a 5 alarm fire 
> 10 minutes before they expire :) 
> 
> IMHO, I’d rather keep the commit and use it as a forcing function to knock
> out things like the discussion we’re having right now. Best to do this years in
> advance, so I think the strategy is the right one assuming nothing else goes
> boom.
> 
> I say that all as a backseat driver here, so that’s just my 2 cents! 
> 
> Thanks again,
> Jon

This regression was already fixed upstream by commit 366284cfbc8f
("KEYS: trusted_tpm1: Use SHA-1 library instead of crypto_shash").
It could be backported to 6.17 if needed.

Of course, the reason it fixed the regression is that it implicitly
dropped the broken and untested fips_enabled check.

Which is clearly the correct choice for now.

But for future reference, if the people doing FIPS certifications of the
whole kernel actually determine that a particular kernel feature(s) that
use SHA-1 *must* be disabled when fips_enabled=1, then of course they'll
need to do that properly by submitting a tested and well-justified patch
for each feature that carefully disables the correct functionality.

Submitting a broken, untested, and incomplete patch that makes the
kernel fail to boot and dm-crypt.ko fail to load isn't a great strategy.

- Eric