On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > 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. 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. Jason
