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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 29296C4360C for ; Thu, 26 Sep 2019 13:16:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F025321655 for ; Thu, 26 Sep 2019 13:16:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SYwrdftp"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Ui7A0IxW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F025321655 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/jsCUvETc3o9Vm1pEKmD8iqMpl59rjfIHSZfLyOwFrA=; b=SYwrdftp4E0OGV b9tJVobZHKyjEENMLjhnFbRl4SG7UONnhtvnk/ZAPD1K1kRIXV/qMURGCNm1Mp/0lluVRIt0anMmC uBww7KQcjAFdUfJNZIomcpkcnrgRQfgmLoge5SaMM0HVjw+X3Y6f4EtOD+R0ztT/odnJN6kkzaHnR dC7RwToyhtuEQVO0AyJBPjQS1NrzQEzCAjnSx+whhlDs7BWu10lNQtm9Wfv1ks2Aqmj9hHRLRw9pO VUJx5f5XBuwSyKrzB+zwLIoIGAN4Sgo+SOPNp1s1QnwhX90I5ojK/nPq1ZtbZjnpdOWf5R0cTFZqw 502FUy9J5EJYtcyi4BJg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDTcw-0007Rz-5N; Thu, 26 Sep 2019 13:16:10 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDTct-0007Rb-OU for linux-arm-kernel@lists.infradead.org; Thu, 26 Sep 2019 13:16:09 +0000 Received: by mail-wm1-x344.google.com with SMTP id b24so2527984wmj.5 for ; Thu, 26 Sep 2019 06:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYKCkf/9udb08zDyVDa+j9RshyXNha3pc6th2ByyF9c=; b=Ui7A0IxWRvD0n0EPRBZpCiL8RXAZI/9JhGIUii+M0h6Q8WYWVbYy0nUBC7r3squbUl irrFobTVKHJX3kf4n2zrVZeYwzoTefH4ZWP6FUhvrECNsblCL7Dqm0k7k5Udg33WQaHp 0F3e6q2ovkiS0FX0g/BxfK45pGLxom7LBR2tdpqaU3rTF54kruEBUhnkIsP+/xwFrhVn Uo8ij4fKonWcV1N6ZhF5oxpZ1PwKOEeSIwy4HeUINl2afp7e43/lFpUZaiqlcxezNgXe d80HRJckphF7lqkcfbirFGMlowoIItQF+dcGBtm8Y5fh2hRT4U+zzPVykdybR+hNFP/H lYuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DYKCkf/9udb08zDyVDa+j9RshyXNha3pc6th2ByyF9c=; b=QTrJOXVDAc5Slz0kABCOzEu6+rMZvGKKynkY1tzmK82Azf8KpL5gop4+OyooEM8qkF REOZWUIg0GAXxRbyhqRBg/GPssmTM9yj9LRpHtk4BVPbv76/3tCRKp7r+KYLxbBrqTR4 bFTiinxd/UUC9g3CRhhxHikwohlVyy4yN1wIPIewkJoxa7/GomP6neBBMM8vNIkwA34X aaqlZBDA6bV8gcV78emiina+u1bQZpzAOev3TGseI/xp/Zg39+JKQSb+QAdZlzDXCGDZ e5yVr8ZZsDVvRmlfW1HYlkhimoSGRGbXCBCW2SJOOb4D+c5Fdn3+XBoMRZjzDJemNnnj nN6Q== X-Gm-Message-State: APjAAAU2XRs3V3yR773/fhvVvdv2myXFY7FZglSMDTWUHdYa5fbsCLXW hdCJ7gFrA9A3lUR5MBCcG1K/uHPrX+qJ17cMGVofsIqhuFI= X-Google-Smtp-Source: APXvYqxJi0lkkMXSCOu7S2Y50VqJ9EZ89R56Po9SG6oZxbjYPkG0NwzF/unO72G5Jlie6aCd2LhWvNpvk/J3Ul2zGKg= X-Received: by 2002:a1c:e906:: with SMTP id q6mr2812638wmc.136.1569503763943; Thu, 26 Sep 2019 06:16:03 -0700 (PDT) MIME-Version: 1.0 References: <20190925161255.1871-1-ard.biesheuvel@linaro.org> In-Reply-To: From: Ard Biesheuvel Date: Thu, 26 Sep 2019 15:15:52 +0200 Message-ID: Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API To: Pascal Van Leeuwen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190926_061607_869661_84E95B2F X-CRM114-Status: GOOD ( 16.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A. Donenfeld" , Catalin Marinas , Herbert Xu , Arnd Bergmann , Eric Biggers , Greg KH , Samuel Neves , Will Deacon , Linux Crypto Mailing List , Andy Lutomirski , Marc Zyngier , Dan Carpenter , Linus Torvalds , David Miller , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen wrote: ... > > > > My preference would be to address this by permitting per-request keys > > in the AEAD layer. That way, we can instantiate the transform only > > once, and just invoke it with the appropriate key on the hot path (and > > avoid any per-keypair allocations) > > > This part I do not really understand. Why would you need to allocate a > new transform if you change the key? Why can't you just call setkey() > on the already allocated transform? > Because the single transform will be shared between all users running on different CPUs etc, and so the key should not be part of the TFM state but of the request state. > > > > It all depends on whether we are interested in supporting async > > accelerators or not, and it is clear what my position is on this > > point. > > > Maybe not for an initial upstream, but it should be a longer-term goal. > > > > > What I *don't* want is to merge WireGuard with its own library based > > crypto now, and extend that later for async accelerators once people > > realize that we really do need that as well. > > > What's wrong with a step-by-step approach though? i.e. merge it with > library calls now and then gradually work towards the goal of integrating > (a tweaked version of) the Crypto API where that actually makes sense? > Rome wasn't built in one day either ... > I should clarify: what I don't want is two frameworks in the kernel for doing async crypto, the existing one plus a new library-based one. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel