Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode

On Fri, 2021-04-09 at 08:02 +0200, Ard Biesheuvel wrote:

On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld [off-list ref] wrote:

quoted

On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:

quoted

On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:

quoted

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