[PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

xxhash64 is not a cryptographic hash algorithm, but is offered in the
same API (shash) as actual cryptographic hash algorithms such as
SHA-256. The Cryptographic Module Validation Program (CMVP), managing
FIPS certification, believes that this could cause confusion. xxhash64
must therefore be blocked in FIPS mode.

The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
("btrfs: switch to library APIs for checksums") recently modified the
btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
mode should now have no impact on btrfs usage.

Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
---
 crypto/testmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 49b607f65f63..d7475d6000dd 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5609,7 +5609,6 @@ static const struct alg_test_desc alg_test_descs[] = {
 #endif
 		.alg = "xxhash64",
 		.test = alg_test_hash,
-		.fips_allowed = 1,
 		.suite = {
 			.hash = __VECS(xxhash64_tv_template)
 		}
-- 
2.53.0

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Christoph Hellwig]

On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
> xxhash64 is not a cryptographic hash algorithm, but is offered in the
> same API (shash) as actual cryptographic hash algorithms such as
> SHA-256. The Cryptographic Module Validation Program (CMVP), managing
> FIPS certification, believes that this could cause confusion. xxhash64
> must therefore be blocked in FIPS mode.
> 
> The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
> ("btrfs: switch to library APIs for checksums") recently modified the
> btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
> API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
> mode should now have no impact on btrfs usage.

It sounds like xxhash should be removed the crypto API entirely.
There's no user of it, it's not crypto, and doing xxhash through
the userspace crypto API socket is so stupid that I doubt anyone
attempted it.

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Eric Biggers]

[+Cc dm-devel@lists.linux.dev]

On Tue, Mar 03, 2026 at 07:09:26AM -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
> > xxhash64 is not a cryptographic hash algorithm, but is offered in the
> > same API (shash) as actual cryptographic hash algorithms such as
> > SHA-256. The Cryptographic Module Validation Program (CMVP), managing
> > FIPS certification, believes that this could cause confusion. xxhash64
> > must therefore be blocked in FIPS mode.
> > 
> > The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
> > ("btrfs: switch to library APIs for checksums") recently modified the
> > btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
> > API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
> > mode should now have no impact on btrfs usage.
> 
> It sounds like xxhash should be removed the crypto API entirely.
> There's no user of it, it's not crypto, and doing xxhash through
> the userspace crypto API socket is so stupid that I doubt anyone
> attempted it.

dm-integrity, which uses crypto_shash and accepts arbitrary hash
algorithm strings from userspace, might be relying on "xxhash64" being
supported in crypto_shash.  The integritysetup man page specifically
mentions xxhash64:

     --integrity, -I algorithm
         Use  internal  integrity  calculation (standalone mode). The integrity
         algorithm can be CRC (crc32c/crc32), a non-cryptographic hash function
         (xxhash64) or a hash function (sha1, sha256).

         For HMAC (hmac-sha256), you must specify  an  integrity  key  and  its
         size.

Maybe the device-mapper maintainers have some insight into whether
anyone is actually using xxhash64 with dm-integrity.

If yes, then dm-integrity could still switch to using the library API
for it.  dm-integrity would just need to gain some helper functions that
call either the xxhash64 library or crypto_shash depending on the
configured algorithm.  If the full set of algorithms being used can be
determined, then dm-integrity could even switch to the library APIs
entirely, like many other kernel subsystems such as btrfs have.

- Eric

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Milan Broz]

On 3/3/26 8:31 PM, Eric Biggers wrote:
> 
> Maybe the device-mapper maintainers have some insight into whether
> anyone is actually using xxhash64 with dm-integrity.

Someone requested to mention it in integritysetup man page
   https://gitlab.com/cryptsetup/cryptsetup/-/issues/632

I think there were more reports people are using it in some specific cases.

Milan

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Christoph Hellwig]

On Tue, Mar 03, 2026 at 11:31:02AM -0800, Eric Biggers wrote:
> > It sounds like xxhash should be removed the crypto API entirely.
> > There's no user of it, it's not crypto, and doing xxhash through
> > the userspace crypto API socket is so stupid that I doubt anyone
> > attempted it.
> 
> dm-integrity, which uses crypto_shash and accepts arbitrary hash
> algorithm strings from userspace, might be relying on "xxhash64" being
> supported in crypto_shash.  The integritysetup man page specifically
> mentions xxhash64:

Oh, ok.  So at least for now we need it, although it would be nice to
convert dm-integrity to lib/crypto/ and limit it to the advertised
algorithms (including xxhash).

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

Thanks for the discussion below, it sounds like I need to ensure 
dm-integrity can use lib/crypto (at least for xxhash64) before blocking 
it in the crypto API.

On 3/4/26 7:09 AM, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 11:31:02AM -0800, Eric Biggers wrote:
>>> It sounds like xxhash should be removed the crypto API entirely.
>>> There's no user of it, it's not crypto, and doing xxhash through
>>> the userspace crypto API socket is so stupid that I doubt anyone
>>> attempted it.
>> dm-integrity, which uses crypto_shash and accepts arbitrary hash
>> algorithm strings from userspace, might be relying on "xxhash64" being
>> supported in crypto_shash.  The integritysetup man page specifically
>> mentions xxhash64:
> Oh, ok.  So at least for now we need it, although it would be nice to
> convert dm-integrity to lib/crypto/ and limit it to the advertised
> algorithms (including xxhash).
>
>

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Herbert Xu]

On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
> xxhash64 is not a cryptographic hash algorithm, but is offered in the
> same API (shash) as actual cryptographic hash algorithms such as
> SHA-256. The Cryptographic Module Validation Program (CMVP), managing
> FIPS certification, believes that this could cause confusion. xxhash64
> must therefore be blocked in FIPS mode.
> 
> The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
> ("btrfs: switch to library APIs for checksums") recently modified the
> btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
> API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
> mode should now have no impact on btrfs usage.
> 
> Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
> ---
>  crypto/testmgr.c | 1 -
>  1 file changed, 1 deletion(-)

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

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

Hi Herbert,

I don't think this one can be applied yet since dm-integrity still uses 
xxhash64 through the crypto API. This would break fips=1 systems that 
use it.

Kind regards,
Joachim

On 3/14/26 12:11 AM, Herbert Xu wrote:
> On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
>> xxhash64 is not a cryptographic hash algorithm, but is offered in the
>> same API (shash) as actual cryptographic hash algorithms such as
>> SHA-256. The Cryptographic Module Validation Program (CMVP), managing
>> FIPS certification, believes that this could cause confusion. xxhash64
>> must therefore be blocked in FIPS mode.
>>
>> The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
>> ("btrfs: switch to library APIs for checksums") recently modified the
>> btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
>> API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
>> mode should now have no impact on btrfs usage.
>>
>> Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
>> ---
>>   crypto/testmgr.c | 1 -
>>   1 file changed, 1 deletion(-)
> Patch applied.  Thanks.

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Herbert Xu]

On Sat, Mar 14, 2026 at 07:43:15PM -0500, Joachim Vandersmissen wrote:
> Hi Herbert,
> 
> I don't think this one can be applied yet since dm-integrity still uses
> xxhash64 through the crypto API. This would break fips=1 systems that use
> it.

OK I've removed the patch.

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

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Thomas Huth]

On 15/03/2026 01.43, Joachim Vandersmissen wrote:
> Hi Herbert,
> 
> I don't think this one can be applied yet since dm-integrity still uses 
> xxhash64 through the crypto API. This would break fips=1 systems that use it.

Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway? If 
xxhash64 isn't FIPS-compliant, nobody should use it for dm-integrity there, 
right? So I doubt that there are any systems out there that use fips=1 and 
use xxhash64 at the same time?

  Thomas

> 
> On 3/14/26 12:11 AM, Herbert Xu wrote:
>> On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
>>> xxhash64 is not a cryptographic hash algorithm, but is offered in the
>>> same API (shash) as actual cryptographic hash algorithms such as
>>> SHA-256. The Cryptographic Module Validation Program (CMVP), managing
>>> FIPS certification, believes that this could cause confusion. xxhash64
>>> must therefore be blocked in FIPS mode.
>>>
>>> The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
>>> ("btrfs: switch to library APIs for checksums") recently modified the
>>> btrfs code to use the lib/crypto API, avoiding the Kernel Cryptographic
>>> API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
>>> mode should now have no impact on btrfs usage.
>>>
>>> Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
>>> ---
>>>   crypto/testmgr.c | 1 -
>>>   1 file changed, 1 deletion(-)
>> Patch applied.  Thanks.
> 

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

Hi Thomas,

On 9/9/26 9:36 AM, Thomas Huth wrote:
> On 15/03/2026 01.43, Joachim Vandersmissen wrote:
>> Hi Herbert,
>>
>> I don't think this one can be applied yet since dm-integrity still 
>> uses xxhash64 through the crypto API. This would break fips=1 systems 
>> that use it.
>
> Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway? 
> If xxhash64 isn't FIPS-compliant, nobody should use it for 
> dm-integrity there, right? So I doubt that there are any systems out 
> there that use fips=1 and use xxhash64 at the same time?

There is a risk that users may not know that xxhash64 is not FIPS 
compliant and would still use it. Especially considering it was marked 
as "fips_allowed = 1" for a while.

Distributions that actually need FIPS validation will probably apply 
this patch anyway and deal with the breakage if it happens.

>
>  Thomas
>
>>
>> On 3/14/26 12:11 AM, Herbert Xu wrote:
>>> On Tue, Mar 03, 2026 at 12:05:09AM -0600, Joachim Vandersmissen wrote:
>>>> xxhash64 is not a cryptographic hash algorithm, but is offered in the
>>>> same API (shash) as actual cryptographic hash algorithms such as
>>>> SHA-256. The Cryptographic Module Validation Program (CMVP), managing
>>>> FIPS certification, believes that this could cause confusion. xxhash64
>>>> must therefore be blocked in FIPS mode.
>>>>
>>>> The only usage of xxhash64 in the kernel is btrfs. Commit fe11ac191ce0
>>>> ("btrfs: switch to library APIs for checksums") recently modified the
>>>> btrfs code to use the lib/crypto API, avoiding the Kernel 
>>>> Cryptographic
>>>> API. Consequently, the removal of xxhash64 from the Crypto API in FIPS
>>>> mode should now have no impact on btrfs usage.
>>>>
>>>> Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
>>>> ---
>>>>   crypto/testmgr.c | 1 -
>>>>   1 file changed, 1 deletion(-)
>>> Patch applied.  Thanks.
>>
>

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Thomas Huth]

On 10/09/2026 05.24, Joachim Vandersmissen wrote:
> Hi Thomas,
> 
> On 9/9/26 9:36 AM, Thomas Huth wrote:
>> On 15/03/2026 01.43, Joachim Vandersmissen wrote:
>>> Hi Herbert,
>>>
>>> I don't think this one can be applied yet since dm-integrity still uses 
>>> xxhash64 through the crypto API. This would break fips=1 systems that use 
>>> it.
>>
>> Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway? If 
>> xxhash64 isn't FIPS-compliant, nobody should use it for dm-integrity 
>> there, right? So I doubt that there are any systems out there that use 
>> fips=1 and use xxhash64 at the same time?
> 
> There is a risk that users may not know that xxhash64 is not FIPS compliant 
> and would still use it. Especially considering it was marked as 
> "fips_allowed = 1" for a while.

So isn't that a very bad situation? They think they are FIPS compliant, but 
actually they are not since they use an unapproved algorithm by accident. 
Maybe it would be better to include this patch so that they are aware of the 
mistake? If there is really somebody running into this issue, they could 
boot once with fips=0, fix their system, reboot again with fips=1 and 
finally be really compliant. Sounds like the better solution to me. WDYT?

  Thomas

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Eric Biggers]

On Thu, Sep 10, 2026 at 10:57:32AM +0200, Thomas Huth wrote:
> On 10/09/2026 05.24, Joachim Vandersmissen wrote:
> > Hi Thomas,
> > 
> > On 9/9/26 9:36 AM, Thomas Huth wrote:
> > > On 15/03/2026 01.43, Joachim Vandersmissen wrote:
> > > > Hi Herbert,
> > > > 
> > > > I don't think this one can be applied yet since dm-integrity
> > > > still uses xxhash64 through the crypto API. This would break
> > > > fips=1 systems that use it.
> > > 
> > > Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway?
> > > If xxhash64 isn't FIPS-compliant, nobody should use it for
> > > dm-integrity there, right? So I doubt that there are any systems out
> > > there that use fips=1 and use xxhash64 at the same time?
> > 
> > There is a risk that users may not know that xxhash64 is not FIPS
> > compliant and would still use it. Especially considering it was marked
> > as "fips_allowed = 1" for a while.
> 
> So isn't that a very bad situation? They think they are FIPS compliant, but
> actually they are not since they use an unapproved algorithm by accident.
> Maybe it would be better to include this patch so that they are aware of the
> mistake? If there is really somebody running into this issue, they could
> boot once with fips=0, fix their system, reboot again with fips=1 and
> finally be really compliant. Sounds like the better solution to me. WDYT?

As described in the dm-integrity documentation, dm-integrity supports
non-cryptographic checksums for protection from accidental corruption.
That use case is no different from any other use case of a checksum.

It's also no different from using crc32 or crc32c, which similarly have
fips_allowed=1 and this patch completely ignores.

The solution is not banning checksums or making any other code change,
but rather just doing what it seems everyone has already been doing:
documenting in their FIPS security policy that checksums are only for
use cases that are not "security functions".

- Eric

Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode

[Joachim Vandersmissen]

Hi Eric,

On 9/10/26 9:14 AM, Eric Biggers wrote:
> On Thu, Sep 10, 2026 at 10:57:32AM +0200, Thomas Huth wrote:
>> On 10/09/2026 05.24, Joachim Vandersmissen wrote:
>>> Hi Thomas,
>>>
>>> On 9/9/26 9:36 AM, Thomas Huth wrote:
>>>> On 15/03/2026 01.43, Joachim Vandersmissen wrote:
>>>>> Hi Herbert,
>>>>>
>>>>> I don't think this one can be applied yet since dm-integrity
>>>>> still uses xxhash64 through the crypto API. This would break
>>>>> fips=1 systems that use it.
>>>> Out of curiosity: Wouldn't such a system be FIPS-incompliant anyway?
>>>> If xxhash64 isn't FIPS-compliant, nobody should use it for
>>>> dm-integrity there, right? So I doubt that there are any systems out
>>>> there that use fips=1 and use xxhash64 at the same time?
>>> There is a risk that users may not know that xxhash64 is not FIPS
>>> compliant and would still use it. Especially considering it was marked
>>> as "fips_allowed = 1" for a while.
>> So isn't that a very bad situation? They think they are FIPS compliant, but
>> actually they are not since they use an unapproved algorithm by accident.
>> Maybe it would be better to include this patch so that they are aware of the
>> mistake? If there is really somebody running into this issue, they could
>> boot once with fips=0, fix their system, reboot again with fips=1 and
>> finally be really compliant. Sounds like the better solution to me. WDYT?
> As described in the dm-integrity documentation, dm-integrity supports
> non-cryptographic checksums for protection from accidental corruption.
> That use case is no different from any other use case of a checksum.
>
> It's also no different from using crc32 or crc32c, which similarly have
> fips_allowed=1 and this patch completely ignores.
>
> The solution is not banning checksums or making any other code change,
> but rather just doing what it seems everyone has already been doing:
> documenting in their FIPS security policy that checksums are only for
> use cases that are not "security functions".

Unfortunately, this is not an option anymore due to the opinion of the 
CMVP that was issued back in March. If you have an account (you can sign 
up for free), you can read it in full here: 
https://cmuf-workspace.org/Products/Projects/Messages.aspx?prjID=3&id=559. 
I can also send a copy of the PDF file privately, if necessary.

The relevant text is:

     1.a. Can xxhash64 be used in approved mode as non-security function 
without any further action (in this case FIPS IG 2.4.A will not be 
applicable)?

     Answer: No, xxhash64 cannot be understood as a non-security 
function because:
     1) It is offered as an equivalent hash alternative to approved hash 
algorithms (i.e., SHA) using the same interface/API and therefore 
appears to an operator that it can provide cryptographic protection 
(i.e., security).
     2) Its return value (i.e., mode indicator) is the same as for 
approved cryptographic functions that provide security.
     3) It is accessed by an interface/API that has “crypto” in the name 
and thus implies security.
     4) It is an available hash function (i.e. PRF) of HMAC, which is a 
keyed algorithm that implies security.

crc32 and crc32c were not explicitly called out in the resolution, which 
is why this patch didn't target them. Though following the same 
rationale, they should also be disabled.

>
> - Eric