On Fri, 2021-04-09 at 12:36 -0600, Jason A. Donenfeld wrote: > On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce <s...@redhat.com> 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.
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
