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

[Thomas Huth]

On 11/09/2026 04.53, Joachim Vandersmissen wrote:
> 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.

Ok, thanks for making this clear. So that means for FIPS certification, 
xxhash64 *has* to be disabled in fips_enabled mode, right? Thus every distro 
that cares for FIPS certification has to include this patch. Every other 
distro doesn't care for fips_enabled anyway, so they should not care about 
this patch whether it's applied or not. I.e. there cannot be any user who 
uses xxhash64 in a fips_enabled system (unless someone is masochistic enough 
to turn it on with an upstream kernel in a environment that does not need 
FIPS compliance). So I think we really should include this patch into the 
upstream kernel now, too. WDYT?

> 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.
Sounds reasonable to me, but maybe this can wait 'til the CMVP explicitely 
asks for it?

  Thomas