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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d6137d0e4ea1d67ee495398f2cb12a1c21653fd.camel@redhat.com>
Date:   Fri, 09 Apr 2021 14:56:05 -0400
From:   Simo Sorce <simo@...hat.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Hangbin Liu <liuhangbin@...il.com>,
        Netdev <netdev@...r.kernel.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "herbert.xu" <herbert.xu@...hat.com>
Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode

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