Re: [PATCH] crypto: aead: add service indicator flag for RFC4106 AES-GCM

[Eric Biggers]

On Thu, Mar 12, 2026 at 10:00:59AM -0400, Jeff Barnes wrote:
> 
> 
> On 3/2/26 22:37, Herbert Xu wrote:
> > On Mon, Mar 02, 2026 at 04:51:38PM -0500, Jeff Barnes wrote:
> > > 
> > > For instance, ceph, samba, tls, to name a few. They all instantiate the
> > > gcm(aes) template. They all construct their own IV. They are all compliant
> > > to SP 800-38d. I am pretty sure that at least one constructs it per 8.2.2
> > > while the rest construct per 8.2.1.
> > 
> > Perhaps they could switch to IV generation in a way that's similar
> > to seqiv?
> Actually, there's no need to do that. They are all compliant already with
> the spec.
> 
> The issue according to the CMVP (NIST) is that because the kernel crypto api
> is, well, an api, that it is *possible* to instantiate the gcm(aes) template
> and generate an IV in a non-compliant way. Even when pressing the point that
> the kernel is monolithic, hence self-contained, and booted with
> lockdown=integrity, the point is lost on the certifying body. Their response
> is to implement the service indicator "like all the other distros". That is
> a very unfortunate way of putting it. It is what it is.
> 
> So currently, for the kernel (crypto api) to pass FIPS 140-3 certification,
> the only viable solution is to either implement the out-of-tree patch or
> disallow gcm(aes) in FIPS mode. Of the two, the out-of-tree patch is
> expensive but the lesser of the two evils.
> 
> I like the idea of automatically switching to seqiv or rfc4106 templates
> when in FIPS mode. The unfortunate consequence is scale. There are 24
> gcm(aes) template instantiations spread out through the kernel tree with
> about as many maintainers. Each of them generate an IV. That seems to me to
> be too large scale.
> 
> Please reconsider.

This whole exercise seems awfully silly, given that no code is actually
going to check the CRYPTO_TFM_FIPS_COMPLIANCE flag, either upstream or
downstream.  So this is just unused code which exists only to satisfy a
check box for something that FIPS 140 says has to be there but is never
used in practice.  While upstream does have limited support for FIPS
140, that limited support tends to be for things which at least actually
do *something*, not completely unused code.

I guess I have to ask, if the theoretical possibility of code calling
'crypto_tfm_get_flags(tfm) & CRYPTO_TFM_FIPS_COMPLIANCE' is sufficient
to count as a service indicator for AES-GCM, is there any reason why the
procedure for retrieving the service indicator can't be something like
'strncmp("seqiv(", crypto_tfm_alg_name(tfm), 6) == 0'?  That would
effectively be the same thing, and it wouldn't require any new code.

If that's not enough and your FIPS certification lab will only accept
the solution with unused code, I don't think that's very compatible with
upstream, sorry.  Any unused code upstream is going to tend to be
removed, as per the usual kernel development practices.

- Eric