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

["Theodore Ts'o" <tytso@mit.edu>]

On Sun, Oct 05, 2025 at 09:29:21AM +0200, Vegard Nossum wrote:
> This sounds like a good idea to me, although I suspect it would be more
> useful as static CONFIG_* options than boot-time options.

I suspect that distributions would have problems with static CONFIG_*
options, because it means they have to chose which FIPS options to
work (and which kerenlk features to neuter, and hence, which customers
to p*ss off).

What's not clear to me is whether some of the interpretions that if
*any* SHA1 implementations are shipped with the product, then ix-nay
on getting FIPS certification.  If that is true, then perhaps static
CONFIG_* options would be needed.  I don't see that in the FIPS
specifications; only in click-baity headlines --- but I might have
missed something, since I don't have to deal with FIPS certification,
for which I am infinitely grateful.  :-)

(And if it is true, then the boot-line fips=1 would be useless for the
purposes of getting that magic piece of fips certification paper, and
people don't seem to beieve that's the case, or it wouldn't exist.)


The other thing to note that for better or worse, FIPS compliance
might be rquired for use cases other than selling into the US
Government market.  For example, PCI requires FIPS compliance when
encrypting credit card data.  But PCI might not care about whether you
are using SHA-1 for dm_crypt, so long as you're not storing critical
card data or other PII on it.  So that might be a situation where
subsystem-specific enablement of FIPS mode might make sense.

Cheers,

						- Ted