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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 7CC82ECE564 for ; Tue, 18 Sep 2018 21:01:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3926020C0E for ; Tue, 18 Sep 2018 21:01:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="fkIxkXJH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3926020C0E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=zx2c4.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730473AbeISCfs (ORCPT ); Tue, 18 Sep 2018 22:35:48 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:43269 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729859AbeISCfr (ORCPT ); Tue, 18 Sep 2018 22:35:47 -0400 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8b11e3e3; Tue, 18 Sep 2018 20:43:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=mail; bh=2FXvB690QsOQefcZErXGaYju0hY=; b=fkIxkXJ HfPqyws9Xc1aUkP9XDBkAp7eE5iKaOLP1Vtc96GRJGOHVtZwcID/L8fHtCvdZtYV uC8RzoMBORgVOCGYiB9DV1LZN4NdVumpjiA6RaXdTYkBAsnr3fWOgRZgOb24s9Sm tN7l/wcMr9cRIzm0xP1kqzkWDpoixQryeGCvAjUTInNm9V8c+msF3kkYeP3jGu3U vtSO4Zmp1NpvhZIusceopw5MpnYpw0iwcyVcwCM4Sd1FI/zUKwBYtiD+2DXLsaxB gibNOS0BgY1HeMl71PCHDFTs8mJuxcZm5KjngOflelbPIgRTJIUR1ps7GcxPiG2w 2bcr/rJJnad54EQ== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c1c54e8d (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 18 Sep 2018 20:43:46 +0000 (UTC) Date: Tue, 18 Sep 2018 23:01:21 +0200 From: "Jason A. Donenfeld" To: Ard Biesheuvel Cc: Linux Kernel Mailing List , "" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , "David S. Miller" , Greg Kroah-Hartman Subject: Re: [PATCH net-next v5 00/20] WireGuard: Secure Network Tunnel Message-ID: <20180918210120.GA29812@zx2c4.com> References: <20180918161646.19105-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, On Tue, Sep 18, 2018 at 11:28:50AM -0700, Ard Biesheuvel wrote: > On 18 September 2018 at 09:16, Jason A. Donenfeld wrote: > > - While I initially wasn't going to do this for the initial > > patchset, it was just so simple to do: now there's a nosimd > > module parameter that can be used to disable simd instructions > > for debugging and testing, or on weird systems. > > > > I was going to respond in the other thread but it is probably better > to move the discussion here. > > My concern about the monolithic nature of each algo module is not only > about SIMD, and it has nothing to do with weird systems. It has to do > with micro-architectural differences which are more common on ARM than > on other architectures *, I suppose. But generalizing from that, it > has to do with policy which is currently owned by userland and not by > the kernel. This will also be important for choosing between the time > variant but less safe table based scalar AES and the much slower time > invariant version (which is substantially slower, especially on > decryption) once we move AES into this library. > > So a command line option for the kernel is not the solution here. If > we can't have separate modules, could we at least have per-module > options that put the policy decisions back into userland? > > * as an example, the SHA256 NEON code I collaborated on with Andy > Polyakov 2 years ago is significantly faster on some cores and not on > others Interesting concern. There are micro-architectural quirks on x86 too that the current code actually already considers. Notably, we use an AVX-512VL path for Skylake-X but an AVX-512F path for Knights Landing and Coffee Lake and others, due to thermal throttling when touching the zmm registers on Skylake-X. So, in the code, we have it automatically select the right thing based on the micro-architecture. Is the same thing not possible with ARM? Do you not have access to this information already, such that the module can just always do the right thing and not require any user intervention? If so, that would be ideal. If not (and I'm curious to learn why not exactly), then indeed we could add some runtime nobs in /sys/module/ {algo}/parameters/{nob}, or the like. This would be super easy to do, should we ever encounter a situation where we're unable to auto-detect the correct thing. Regards, Jason