From patchwork Tue Nov 20 06:02:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Herbert Xu X-Patchwork-Id: 10689879 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1D7AD16B1 for ; Tue, 20 Nov 2018 06:02:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F3AEB2A3DC for ; Tue, 20 Nov 2018 06:02:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E70832A3EF; Tue, 20 Nov 2018 06:02:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6044E2A3DC for ; Tue, 20 Nov 2018 06:02:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732209AbeKTQ3y (ORCPT ); Tue, 20 Nov 2018 11:29:54 -0500 Received: from orcrist.hmeau.com ([104.223.48.154]:45356 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732199AbeKTQ3y (ORCPT ); Tue, 20 Nov 2018 11:29:54 -0500 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1gOz7B-0000Ca-SE; Tue, 20 Nov 2018 14:02:26 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1gOz73-00065g-AM; Tue, 20 Nov 2018 14:02:17 +0800 Date: Tue, 20 Nov 2018 14:02:17 +0800 From: Herbert Xu To: "Jason A. Donenfeld" Cc: Eric Biggers , Ard Biesheuvel , Linux Crypto Mailing List , linux-fscrypt@vger.kernel.org, linux-arm-kernel@lists.infradead.org, LKML , Paul Crowley , Greg Kaiser , Samuel Neves , Tomer Ashur , Martin Willi Subject: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Message-ID: <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> References: <20181105232526.173947-1-ebiggers@kernel.org> <20181105232526.173947-11-ebiggers@kernel.org> <20181112185816.GA8663@gmail.com> <20181116060227.hwu4igi6bp26ddpi@gondor.apana.org.au> <20181117001718.GA175522@gmail.com> <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Nov 19, 2018 at 01:24:51PM +0800, Herbert Xu wrote: > > In response to Martin's patch-set which I merged last week, I think > here is quick way out for the zinc interface. > > Going through the past zinc discussions it would appear that > everybody is quite happy with the zinc interface per se. The > most contentious areas are in fact the algorithm implementations > under zinc, as well as the conversion of the crypto API algorithms > over to using the zinc interface (e.g., you can no longer access > specific implementations). > > My proposal is to merge the zinc interface as is, but to invert > how we place the algorithm implementations. IOW the implementations > should stay where they are now, with in the crypto API. However, > we will provide direct access to them for zinc without going through > the crypto API. IOW we'll just export the functions directly. > > Here is a proof of concept patch to do it for chacha20-generic. > It basically replaces patch 3 in the October zinc patch series. > Actually this patch also exports the arm/x86 chacha20 functions > too so they are ready for use by zinc. > > If everyone is happy with this then we can immediately add the > zinc interface and expose the existing crypto API algorithms > through it. This would allow wireguard to be merged right away. > > In parallel, the discussions over replacing the implementations > underneath can carry on without stalling the whole project. > > PS This patch is totally untested :) Here is an updated version demonstrating how we could access the accelerated versions of chacha20. It also includes a final patch to deposit the new zinc version of x86-64 chacha20 into arch/x86/crypto where it can be used by both the crypto API as well as zinc. The key differences between this and the last zinc patch series: 1. The crypto API algorithms remain individually accessible, this is crucial as these algorithm names are exported to user-space so changing the names to foo-zinc is not going to work. 2. The arch-specific algorithm code lives in their own module rather than in a monolithic module. Cheers,