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

Joachim Vandersmissen joachim at jvdsn.com
Wed Sep 9 20:24:42 PDT 2026


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 at jvdsn.com>
>>>> ---
>>>>   crypto/testmgr.c | 1 -
>>>>   1 file changed, 1 deletion(-)
>>> Patch applied.  Thanks.
>>
>



More information about the linux-arm-kernel mailing list