[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