Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <01fae6c3113d454cc009f065fde77f66af9845b6.camel@redhat.com>
Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode
From:   Simo Sorce <simo@redhat.com>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Hangbin Liu <liuhangbin@gmail.com>,
        Netdev <netdev@vger.kernel.org>,
        Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@redhat.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Ondrej Mosnacek <omosnace@redhat.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "herbert.xu" <herbert.xu@redhat.com>
Date:   Mon, 12 Apr 2021 08:46:28 -0400
In-Reply-To: <5d6137d0e4ea1d67ee495398f2cb12a1c21653fd.camel@redhat.com>
References: <20210407113920.3735505-1-liuhangbin@gmail.com>
         <CAHmME9p40M5oHDZXnFDXfO4-JuJ7bUB5BnsccGV1pksguz73sg@mail.gmail.com>
         <c47d99b9d0efeea4e6cd238c2affc0fbe296b53c.camel@redhat.com>
         <CAHmME9pRSOANrdvegLm9x8VTNWKcMtoymYrgStuSx+nsu=jpwA@mail.gmail.com>
         <20210409024143.GL2900@Leo-laptop-t470s>
         <CAHmME9oqK9iXRn3wxAB-MZvX3k_hMbtjHF_V9UY96u6NLcczAw@mail.gmail.com>
         <20210409024907.GN2900@Leo-laptop-t470s> <YG/EAePSEeYdonA0@zx2c4.com>
         <CAMj1kXG-e_NtLkAdLYp70x5ft_Q1Bn9rmdXs4awt7FEd5PQ4+Q@mail.gmail.com>
         <0ef180dea02996fc5f4660405f2333220e8ae4c4.camel@redhat.com>
         <CAHmME9opMi_2_cOS66U6jJvYZ=WJWv4E-mjYr20YaL=zzJxv+Q@mail.gmail.com>
         <5d6137d0e4ea1d67ee495398f2cb12a1c21653fd.camel@redhat.com>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 2021-04-09 at 14:56 -0400, Simo Sorce wrote:
> 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.

Turns out I and Hangbin do work for the same company after all.
Left hand is meeting right hand internally now. :-D
The comments still stand of course.

Simo.

> 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