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,DKIMWL_WL_HIGH, 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 0168EC433B4 for ; Mon, 12 Apr 2021 12:46:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B579561263 for ; Mon, 12 Apr 2021 12:46:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241406AbhDLMrC (ORCPT ); Mon, 12 Apr 2021 08:47:02 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:49423 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241408AbhDLMrA (ORCPT ); Mon, 12 Apr 2021 08:47:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618231602; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gyRA3eXvjPEiAnUmzzROMJvtjDJt+882R/Pm9YO3IBI=; b=JRv7jkM8UeZCBUnQaCQt8+mV98GTZiisYSrZNEZERUz6T2UMnUdbCCrpj1DntLVonZlgJ9 Aqp7hQh3t8b9A/2M/TmTBY+MHWBXq/tKwTl3UoQE9plHF1PVqbFwdIKtGlrJL3W+EHpjB4 ggun5dgSPW4UgPfk7sTpYytseatFmnA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-509-H2Ovd74qMrWeALGVTF0e4Q-1; Mon, 12 Apr 2021 08:46:38 -0400 X-MC-Unique: H2Ovd74qMrWeALGVTF0e4Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E15306D252; Mon, 12 Apr 2021 12:46:36 +0000 (UTC) Received: from ovpn-112-53.phx2.redhat.com (ovpn-112-53.phx2.redhat.com [10.3.112.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A59646090F; Mon, 12 Apr 2021 12:46:29 +0000 (UTC) Message-ID: <01fae6c3113d454cc009f065fde77f66af9845b6.camel@redhat.com> Subject: Re: [PATCH net-next] [RESEND] wireguard: disable in FIPS mode From: Simo Sorce To: "Jason A. Donenfeld" Cc: Ard Biesheuvel , Hangbin Liu , Netdev , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Jakub Kicinski , Ondrej Mosnacek , Linux Crypto Mailing List , "herbert.xu" Date: Mon, 12 Apr 2021 08:46:28 -0400 In-Reply-To: <5d6137d0e4ea1d67ee495398f2cb12a1c21653fd.camel@redhat.com> References: <20210407113920.3735505-1-liuhangbin@gmail.com> <20210409024143.GL2900@Leo-laptop-t470s> <20210409024907.GN2900@Leo-laptop-t470s> <0ef180dea02996fc5f4660405f2333220e8ae4c4.camel@redhat.com> <5d6137d0e4ea1d67ee495398f2cb12a1c21653fd.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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