On Fri, 2021-04-09 at 12:36 -0600, Jason A. Donenfeld wrote:

On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce [off-list ref] wrote:

quoted

quoted

  depends on m || !CRYPTO_FIPS

but I am a bit concerned that the rather intricate kconfig
dependencies between the generic and arch-optimized versions of those
drivers get complicated even further.

Actually this is the opposite direction we are planning to go for
future fips certifications.

Due to requirements about crypto module naming and versioning in the
new FIPS-140-3 standard we are planning to always build all the CRYPTO
as bultin (and maybe even forbid loading additional crypto modules in
FIPS mode). This is clearly just a vendor choice and has no bearing on
what upstream ultimately will do, but just throwing it here as a data
point.

I'm wondering: do you intend to apply similar patches to all the other
uses of "non-FIPS-certified" crypto in the kernel? I've already
brought up big_key.c, for example. Also if you're intent on adding
this check to WireGuard, because it tunnels packets without using
FIPS-certified crypto primitives, do you also plan on adding this
check to other network tunnels that don't tunnel packets using
FIPS-certified crypto primitives? For example, GRE, VXLAN, GENEVE? I'd
be inclined to take this patch more seriously if it was exhaustive and
coherent for your use case. The targeted hit on WireGuard seems
incoherent as a standalone patch, making it hard to even evaluate.

Hi Jason,
I can't speak for Hangbin, we do not work for the same company and I
was not aware of his efforts until this patch landed.
For my part we were already looking at big_key, wireguard and other
areas internally, but were not thinking of sending upstream patches
like these w/o first a good assessment with our teams and lab that they
were proper and sufficient.

 So
I think either you should send an exhaustive patch series that forbids
all use of non-FIPS crypto anywhere in the kernel (another example:
net/core/secure_seq.c) in addition to all tunneling modules that don't
use FIPS-certified crypto, or figure out how to disable the lib/crypto
primitives that you want to be disabled in "fips mode". With a
coherent patchset for either of these, we can then evaluate it.

Yes a cohesive approach would be ideal, but I do not know if pushing
substantially the same checks we have in the Crypto API down to
lib/crypto is the right way to go, I am not oppose but I guess Herbert
would have to chime in here.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc