Re: FIPS requirements in lib/crypto/ APIs

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Sep 18, 2025 at 01:06:47PM -0500, Eric Biggers wrote:
> > I'm more trying to figure out a general approach to address these kinds of
> > requirements. What I usually see in FIPS modules, is that the FIPS module
> > API is as conservative as possible, rather than relying on the callers to
> > perform the FIPS requirement checks.
> 
> Aren't these distros including the modules within their FIPS module
> boundary too?  It seems they would need to.
> 
> Either way, they've been getting their FIPS certificates despite lib/
> including non-FIPS-approved stuff for many years.  So it can't be that
> much of an issue in practice.

What I would recommend for those people who need FIPS certification
(which is a vanishingly small percentage of Linux kernel users, BTW),
that the FIPS module use their own copy of the crypto algorithms, and
*not* depend on kernel lib/crypto interfaces.

Why?  Because FIPS certification is on the binary artifact, and if
there is a high-severity vulnerability. if you are selling into the US
Government market, FEDRAMP requires that you mitigate that
vulnerability within 30 days and that will likely require that you
deploy a new kernel binary.

So it would be useful if the FIPS module doesn't need to change when
your FEDRAMP certification officer requires that you update the
kernel, and if the FIPS module is "the whole kernel", addressing the
high-severity CVE would break the FIPS certification.  So it really is
much better if you can decouple the FIPS module from the rest of the
kernel, since otherwise the FIPS certification mandate and the FEDRAMP
certification mandate could put you in a very uncomfortable place.

It's also why historically many companies who need to provide FIPS
certification will carefully architect their solution so it is only
dependent on userspace crypto.  A number of years ago, I was involved
in a project at a former employer where we separated the crypto core
of the OpenSSL library from the rest of OpenSSL, so that when there
was a buffer overrun in the ASN.1 DER decoding of a certificate (for
example), we could fix it without breaking the FIPS certification of
the crypto core.  And we didn't even *consider* trying add a kernel
crypto dependency.

One of the important things to remember is that as far as FIPS
certification is concerned, the existence of remote privilege attacks
don't matter, so long as you meet all of the FIPS certification
security theatre.  But in the real world, you really want to fix high
severity CVE's....

Cheers,

					- Ted