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

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