On Fri, 2021-04-09 at 08:02 +0200, Ard Biesheuvel wrote: > On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote: > > > On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote: > > > > Since it's just a normal module library, you can simply do this in the > > > > module_init function, rather than deep within registration > > > > abstractions. > > > > > > I did a try but looks it's not that simple. Not sure if it's because > > > wireguard > > > calls the library directly. Need to check more... > > > > Something like the below should work... > > > > The below only works if all the code is modular. initcall return > values are ignored for builtin code, and so the library functions will > happily work regardless of fips_enabled, and there is generally no > guarantee that no library calls can be made before the initcall() is > invoked. > > For ordinary crypto API client code, the algorithm in question may be > an a priori unknown, and so the only sensible place to put this check > is where the algorithms are registered or instantiated. > > For code such as WireGuard that is hardwired to use a single set of > (forbidden! :-)) algorithms via library calls, the simplest way to do > this securely is to disable the whole thing, even though I agree it is > not the most elegant solution. > > If we go with Jason's approach, we would need to mandate each of these > drivers can only be built as a module if the kernel is built with > FIPS-200 support. This is rather trivial by itself, i.e., > > 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. Plus, as you note, it would overly complicate the interfaces. As much as the check in wireguard is inelegant, it is much simpler to understand and is not invasive. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc
