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;
MIME-Version: 1.0
References: <20210407113920.3735505-1-liuhangbin@gmail.com>
 <CAHmME9p40M5oHDZXnFDXfO4-JuJ7bUB5BnsccGV1pksguz73sg@mail.gmail.com> <20210408065231.GI2900@Leo-laptop-t470s>
In-Reply-To: <20210408065231.GI2900@Leo-laptop-t470s>
From:   Ondrej Mosnacek <omosnace@redhat.com>
Date:   Thu, 8 Apr 2021 09:36:44 +0200
Message-ID: <CAFqZXNuk6wqTb+m4ttyU_4UN5TjqSdvUiOJ=peztUUiyY+ReJQ@mail.gmail.com>
Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode
To:     Hangbin Liu <liuhangbin@gmail.com>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Netdev <netdev@vger.kernel.org>,
        =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@redhat.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Apr 8, 2021 at 8:52 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
> On Wed, Apr 07, 2021 at 03:15:51PM -0600, Jason A. Donenfeld wrote:
> > Hi Hangbin,
> >
> > On Wed, Apr 7, 2021 at 5:39 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
> > >
> > > As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> > > FIPS certified, the WireGuard module should be disabled in FIPS mode.
> >
> > I'm not sure this makes so much sense to do _in wireguard_. If you
> > feel like the FIPS-allergic part is actually blake, 25519, chacha, and
> > poly1305, then wouldn't it make most sense to disable _those_ modules
> > instead? And then the various things that rely on those (such as
> > wireguard, but maybe there are other things too, like
> > security/keys/big_key.c) would be naturally disabled transitively?
>
> Hi Jason,
>
> I'm not familiar with the crypto code. From wg_noise_init() it looks the init
> part is in header file. So I just disabled wireguard directly.
>
> For disabling the modules. Hi Ondrej, do you know if there is any FIPS policy
> in crypto part? There seems no handler when load not allowed crypto modules
> in FIPS mode.

If I understand your question correctly, yes, there is a mechanism
that disables not-FIPS-approved algorithms/drivers in FIPS mode (not
kernel modules themselves, AFAIK). So if any part of the kernel tries
to use e.g. chacha20 via the Crypto API (the bits in crypto/...), it
will fail. I'm not sure about the direct library interface (the bits
in lib/crypto/...) though... That's relatively new and I haven't been
following the upstream development in this area that closely for some
time now...

>
> BTW, I also has a question, apart from the different RFC standard, what's the
> relation/difference between crypto/chacha20poly1305.c and lib/crypto/chacha20poly1305.c?
>
> Thanks
> Hangbin
>

-- 
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.