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

Next message: Krzysztof Kozlowski: "Re: [PATCH v3 3/3] Add socfpga devicetree for Draeger's M48 board."
Previous message: Michael Margolin: "Re: [PATCH rdma-next 1/2] RDMA/efa: Keep admin queues alive while IRQ is registered"
In reply to: Joachim Vandersmissen: "Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode"
Next in thread: Eric Biggers: "Re: [PATCH] crypto: testmgr - block Crypto API xxhash64 in FIPS mode"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

From: Thomas Huth

Date: Thu Sep 10 2026 - 05:04:49 EST

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