[PATCH] crypto/testmgr.c: desupport SHA-1 for FIPS 140

[PATCH] crypto/testmgr.c: desupport SHA-1 for FIPS 140

[Vegard Nossum]

The sunset period of SHA-1 is approaching [1] and FIPS 140 certificates
have a validity of 5 years. Any distros starting FIPS certification for
their kernels now would therefore most likely end up on the NIST
Cryptographic Module Validation Program "historical" list before their
certification expires.

While SHA-1 is technically still allowed until Dec. 31, 2030, it is
heavily discouraged by NIST and it makes sense to set .fips_allowed to
0 now for any crypto algorithms that reference it in order to avoid any
costly surprises down the line.

[1]: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

Acked-by: Stephan Mueller <smueller@chronox.de>
Cc: Marcus Meissner <meissner@suse.de>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: John Haxby <john.haxby@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 crypto/testmgr.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 82977ea25db39..797613daf7e33 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4285,7 +4285,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 	}, {
 		.alg = "authenc(hmac(sha1),cbc(aes))",
 		.test = alg_test_aead,
-		.fips_allowed = 1,
 		.suite = {
 			.aead = __VECS(hmac_sha1_aes_cbc_tv_temp)
 		}
@@ -4304,7 +4303,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 	}, {
 		.alg = "authenc(hmac(sha1),ctr(aes))",
 		.test = alg_test_null,
-		.fips_allowed = 1,
 	}, {
 		.alg = "authenc(hmac(sha1),ecb(cipher_null))",
 		.test = alg_test_aead,
@@ -4314,7 +4312,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 	}, {
 		.alg = "authenc(hmac(sha1),rfc3686(ctr(aes)))",
 		.test = alg_test_null,
-		.fips_allowed = 1,
 	}, {
 		.alg = "authenc(hmac(sha224),cbc(des))",
 		.test = alg_test_aead,
@@ -5156,7 +5153,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 	}, {
 		.alg = "hmac(sha1)",
 		.test = alg_test_hash,
-		.fips_allowed = 1,
 		.suite = {
 			.hash = __VECS(hmac_sha1_tv_template)
 		}
@@ -5498,7 +5494,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 	}, {
 		.alg = "sha1",
 		.test = alg_test_hash,
-		.fips_allowed = 1,
 		.suite = {
 			.hash = __VECS(sha1_tv_template)
 		}
-- 
2.34.1

Re: [PATCH] crypto/testmgr.c: desupport SHA-1 for FIPS 140

[Herbert Xu]

On Wed, May 21, 2025 at 02:55:19PM +0200, Vegard Nossum wrote:
> The sunset period of SHA-1 is approaching [1] and FIPS 140 certificates
> have a validity of 5 years. Any distros starting FIPS certification for
> their kernels now would therefore most likely end up on the NIST
> Cryptographic Module Validation Program "historical" list before their
> certification expires.
> 
> While SHA-1 is technically still allowed until Dec. 31, 2030, it is
> heavily discouraged by NIST and it makes sense to set .fips_allowed to
> 0 now for any crypto algorithms that reference it in order to avoid any
> costly surprises down the line.
> 
> [1]: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
> 
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Cc: Marcus Meissner <meissner@suse.de>
> Cc: Jarod Wilson <jarod@redhat.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: John Haxby <john.haxby@oracle.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  crypto/testmgr.c | 5 -----
>  1 file changed, 5 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Jon Kohler]

> On May 21, 2025, at 8:55 AM, Vegard Nossum <vegard.nossum@oracle.com> wrote:
> 
> The sunset period of SHA-1 is approaching [1] and FIPS 140 certificates
> have a validity of 5 years. Any distros starting FIPS certification for
> their kernels now would therefore most likely end up on the NIST
> Cryptographic Module Validation Program "historical" list before their
> certification expires.
> 
> While SHA-1 is technically still allowed until Dec. 31, 2030, it is
> heavily discouraged by NIST and it makes sense to set .fips_allowed to
> 0 now for any crypto algorithms that reference it in order to avoid any
> costly surprises down the line.
> 
> [1]: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
> 
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Cc: Marcus Meissner <meissner@suse.de>
> Cc: Jarod Wilson <jarod@redhat.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: John Haxby <john.haxby@oracle.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
> crypto/testmgr.c | 5 -----
> 1 file changed, 5 deletions(-)
> 
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 82977ea25db39..797613daf7e33 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -4285,7 +4285,6 @@ static const struct alg_test_desc alg_test_descs[] = {
> }, {
> .alg = "authenc(hmac(sha1),cbc(aes))",
> .test = alg_test_aead,
> - .fips_allowed = 1,
> .suite = {
> .aead = __VECS(hmac_sha1_aes_cbc_tv_temp)
> }
> @@ -4304,7 +4303,6 @@ static const struct alg_test_desc alg_test_descs[] = {
> }, {
> .alg = "authenc(hmac(sha1),ctr(aes))",
> .test = alg_test_null,
> - .fips_allowed = 1,
> }, {
> .alg = "authenc(hmac(sha1),ecb(cipher_null))",
> .test = alg_test_aead,
> @@ -4314,7 +4312,6 @@ static const struct alg_test_desc alg_test_descs[] = {
> }, {
> .alg = "authenc(hmac(sha1),rfc3686(ctr(aes)))",
> .test = alg_test_null,
> - .fips_allowed = 1,
> }, {
> .alg = "authenc(hmac(sha224),cbc(des))",
> .test = alg_test_aead,
> @@ -5156,7 +5153,6 @@ static const struct alg_test_desc alg_test_descs[] = {
> }, {
> .alg = "hmac(sha1)",
> .test = alg_test_hash,
> - .fips_allowed = 1,
> .suite = {
> .hash = __VECS(hmac_sha1_tv_template)
> }
> @@ -5498,7 +5494,6 @@ static const struct alg_test_desc alg_test_descs[] = {
> }, {
> .alg = "sha1",
> .test = alg_test_hash,
> - .fips_allowed = 1,
> .suite = {
> .hash = __VECS(sha1_tv_template)
> }

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

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

[Vegard Nossum]

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

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?


Vegard

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

[Jon Kohler]

> 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

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

[Eric Biggers]

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

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]

On Sat, Oct 04, 2025 at 04:24:51PM -0700, Eric Biggers wrote:
> 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.

There's a hidden philosopical question here, which is whether "FIPS
certification of the whole kernel" is actually a good thing.
Personally, I don't think it is, but if booting with fips=1 neuters a
whole bunch of kernel features, and that is considered "working as
intended", to the extent that it discourages the use of FIPS mode,
maybe it's not such a bad thing.  :-)

But with that said, I suspect one of the things that distributions
might find useful is per-kernel subsystem fips enablement.  (e.g.,
dm_crypt.fips=1 which might make a whole bunch of existing users' file
systems become useless, precepitating a whole bunch of angry inquiries
to the distrobution's help desk, but maybe a particular user only needs
ipsec.fips=1)

						- Ted

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

[Vegard Nossum]

On 05/10/2025 05:16, Theodore Ts'o wrote:
> On Sat, Oct 04, 2025 at 04:24:51PM -0700, Eric Biggers wrote:
>> 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.
> 
> There's a hidden philosopical question here, which is whether "FIPS
> certification of the whole kernel" is actually a good thing.

Agree, and it's an important one. In mainline that's the only option, of
course.

> Personally, I don't think it is, but if booting with fips=1 neuters a
> whole bunch of kernel features, and that is considered "working as
> intended", to the extent that it discourages the use of FIPS mode,
> maybe it's not such a bad thing.  :-)

I don't think anybody uses FIPS mode for the sheer joy of it. Usually
it's a requirement for certain types of workloads, meaning you either
have to or you don't. I don't think discouraging it (deliberately or
not) will move the needle much either way.

> But with that said, I suspect one of the things that distributions
> might find useful is per-kernel subsystem fips enablement.  (e.g.,
> dm_crypt.fips=1 which might make a whole bunch of existing users' file
> systems become useless, precepitating a whole bunch of angry inquiries
> to the distrobution's help desk, but maybe a particular user only needs
> ipsec.fips=1)

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'm also not sure if it makes sense without also having a standalone
FIPS module. It doesn't sound in-spec for dm-crypt to use SHA1 inside a
FIPS module if FIPS disallows the use of SHA1, for example, whereas it
might still make sense for a non-certified part of the kernel to use
SHA1 for this purpose.


Vegard

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]

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

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

[Vegard Nossum]

On 05/10/2025 01:24, Eric Biggers wrote:
> 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.

Wow, that's a highly unfair characterization :-( The patch was tested,
but the dm-crypt failure only appears in certain configurations that
includes both the hardware and the specific kernel config. Furthermore,
I think the underlying bug was merely exposed by the patch to deprecate
SHA-1 but I'm not looking to point fingers so I'm not going to say more
about that.


Vegard

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

[Eric Biggers]

On Mon, Oct 06, 2025 at 12:44:09PM +0200, Vegard Nossum wrote:
> 
> On 05/10/2025 01:24, Eric Biggers wrote:
> > 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.
> 
> Wow, that's a highly unfair characterization :-( The patch was tested,
> but the dm-crypt failure only appears in certain configurations that
> includes both the hardware and the specific kernel config. Furthermore,
> I think the underlying bug was merely exposed by the patch to deprecate
> SHA-1 but I'm not looking to point fingers so I'm not going to say more
> about that.

To be clear, the patch introduced at least two bugs that broke basic
functionality: the dm-crypt one (related to trusted_tpm1.c) where
dm-crypt.ko failed to load, and the ipv6-sr one where the kernel failed
to boot at all.

- Eric