On 02/10/2025 19:23, Eric Biggers wrote:

On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:

quoted

I'd like to raise a general question about FIPS compliance here,
especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
made available outside of the crypto API and code around the kernel is
making direct use of it

lib/ has had SHA-1 support since 2005.  The recent changes just made the
SHA-1 API more comprehensive and more widely used in the kernel.

Sure, it was available under lib/ but what matters is that there were no
users outside of the crypto API. Adding direct users presumably breaks
the meaning of fips=1 -- which is why I'd like us to work out (and
explicitly document) what fips=1 actually means.

quoted

then this seems to completely subvert the
purpose of CONFIG_CRYPTO_FIPS/fips=1 since it essentially makes the
kernel non-compliant even when booting with fips=1.

Is this expected? Should it be documented?

If calling code would like to choose not to use or allow a particular
crypto algorithm when fips_enabled=1, it's free to do so.

That's far more flexible than the crypto/ approach, which has
historically been problematic since it breaks things unnecessarily.  The
caller can actually do something that makes sense for it, including:

- Deciding whether FIPS requirements even apply to it in the first
   place.  (Considering that it may or may not be implementing something
   that would be considered a "security function" by FIPS.)

- Targeting the disablement to the correct, narrow area.  (Not something
   overly-broad like the entire IPv6 stack, or entire TPM support.)

So: if the people doing FIPS certifications of the whole kernel make a
determination that fips_enabled=1 kernels must not support IPv6 Segment
Routing with HMAC-SHA1 authentication, then they're welcome to send a
patch that makes seg6_genl_sethmac() reject SEG6_HMAC_ALGO_SHA1 if
fips_enabled.  And that would actually correctly disable the SHA-1
support only, rather than disabling the entire IPv6 stack...

I'm pretty sure the use of SHA-1/HMAC inside IPv6 segment routing counts
as a "security function" (as it is used for message authentication) and
thus should be subject to FIPS requirements when booting with fips=1.

Still, for many years lib/ has had APIs for SHA-1 and various
non-FIPS-approved crypto algorithms.  These are used even when
fips_enabled=1.  So, if this was actually important, one would think
these cases would have addressed already.  This is one of the reasons
why I haven't been worrying about adding these checks myself.

I see some direct uses of lib/ algorithms outside the crypto API on
older kernels but at a glance they look mostly like specific drivers
that most distros probably don't even build, which might explain why it
hasn't been a problem in practice.

It's really up to someone who cares (if anyone does) to send patches.

I'd assume most distributions that provide FIPS-certified kernels care.
As far as I can tell, they are all going to run into problems when they
start providing products based on v6.17. Maybe I'm wrong and it comes
down to an interpretation of FIPS requirements and what fips=1 is
intended to do -- again, why I'd like us to work this out and document
it so we have a clear and shared understanding and don't break mainline
FIPS support.

In the meantime, I think it would be good to stop converting more crypto
API users to lib/crypto/ users if it's not crystal clear that it's not a
"security function".

quoted

FIPS also has a bunch of requirements around algorithm testing, for
example that every algorithm shall pass tests before it can be used.
lib/crypto/ has kunit tests, but there is no interaction with
CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
mechanism. This seems like a bad thing for all the distros that are
currently certifying their kernels for FIPS.

As I've said in another thread
(https://lore.kernel.org/linux-crypto/20250917184856.GA2560@quark/ (local),
https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/ (local)),
small patches that add FIPS pre-operational self-tests would generally
be fine, if they are shown to actually be needed and are narrowly scoped
to what is actually needed.  These would be different from and much
simpler than the KUnit tests, which are the real tests.

But again, it's up to someone who cares to send patches.  And again,
lib/ has had SHA-1 since 2005, so this isn't actually new.

What's new is the direct user of lib/crypto/sha1.c outside the crypto
API since commit 095928e7d8018, which is very recent.

I don't think it's a good idea to duplicate all the logic around
FIPS and algorithm testing that already exists in the crypto API for
this exact purpose.


Vegard