From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2D70C433B4 for ; Fri, 9 Apr 2021 18:37:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9125761105 for ; Fri, 9 Apr 2021 18:37:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233332AbhDIShR (ORCPT ); Fri, 9 Apr 2021 14:37:17 -0400 Received: from mail.zx2c4.com ([104.131.123.232]:46534 "EHLO mail.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234273AbhDIShQ (ORCPT ); Fri, 9 Apr 2021 14:37:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1617993421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oSVNwotPAPQJjl+GLbQuN3wvO2qB5A32VRDgEWPG81Q=; b=R5t3fUIg90+qupBtku5bsLYEV+nt2qW7JuUuvNzAi10GKENgHZH60f6G9A5no/Qn997+4j L37xAjd5OE/qhzc6lyIsHOYM983Z8t8qC8jQkCqcgfhQh+Ndu11lowdW33s6UJTOOEWbe5 OMHykg3GgyzG+vJPNPucNV8w7uDkpZU= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 54dfcd07 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 9 Apr 2021 18:37:00 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id o10so7585626ybb.10; Fri, 09 Apr 2021 11:37:00 -0700 (PDT) X-Gm-Message-State: AOAM530TPfRltU9mXOJRECx5A1Rf02xiz3/eHYv5Rmbjs6tnyQPJbagr dMTvAKcvaVDMf04Eza6s5wyjaUFTKUamPqx9BeI= X-Google-Smtp-Source: ABdhPJwk/MDUyxGAQVPcrk6s9phmYdpLpHbR9mLNDuiVI3g/Quu5obxcIhQdk/3kuJv59Ei2bU2uQFJjsQfvGTOFZ2M= X-Received: by 2002:a25:ad0f:: with SMTP id y15mr17665460ybi.306.1617993420125; Fri, 09 Apr 2021 11:37:00 -0700 (PDT) MIME-Version: 1.0 References: <20210407113920.3735505-1-liuhangbin@gmail.com> <20210409024143.GL2900@Leo-laptop-t470s> <20210409024907.GN2900@Leo-laptop-t470s> <0ef180dea02996fc5f4660405f2333220e8ae4c4.camel@redhat.com> In-Reply-To: <0ef180dea02996fc5f4660405f2333220e8ae4c4.camel@redhat.com> From: "Jason A. Donenfeld" Date: Fri, 9 Apr 2021 12:36:49 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode To: Simo Sorce Cc: Ard Biesheuvel , Hangbin Liu , Netdev , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Jakub Kicinski , Ondrej Mosnacek , Linux Crypto Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce 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. 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. Jason