From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Herbert Xu <herbert@gondor.apana.org.au> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, Eric Biggers <ebiggers@kernel.org>, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linux-crypto@vger.kernel.org>, linux-fscrypt@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Paul Crowley <paulcrowley@google.com>, Greg Kaiser <gkaiser@google.com>, Samuel Neves <samuel.c.p.neves@gmail.com>, Tomer Ashur <tomer.ashur@esat.kuleuven.be>, Martin Willi <martin@strongswan.org> Subject: Re: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Date: Tue, 20 Nov 2018 11:32:05 +0100 [thread overview] Message-ID: <CAKv+Gu-SHS2tF665dfqSgmH5EF5vGVtef=3_4WgCE=+8+Jw7Rw@mail.gmail.com> (raw) In-Reply-To: <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> On Tue, 20 Nov 2018 at 07:02, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > 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. > Are you saying user space may use names like "ctr-aes-neon" directly rather than "ctr(aes)" for any implementation of the mode? If so, that is highly unfortunate, since it means we'd be breaking user space by wrapping a crypto library function with its own arch specific specializations into a generic crypto API wrapper. Note that I think that using AF_ALG to access software crypto routines (as opposed to accelerators) is rather pointless to begin with, but if it permits that today than we're stuck with it. > 2. The arch-specific algorithm code lives in their own module rather > than in a monolithic module. > This is one of the remaining issues I have with Zinc. However, modulo the above concerns, I think it does make sense to have a separate function API for synchronous software routines below the current crypto API. What I don't want is a separate Zinc kingdom with a different name, different maintainers and going through a different tree, and with its own approach to test vectors, arch specific code, etc etc
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Date: Tue, 20 Nov 2018 11:32:05 +0100 [thread overview] Message-ID: <CAKv+Gu-SHS2tF665dfqSgmH5EF5vGVtef=3_4WgCE=+8+Jw7Rw@mail.gmail.com> (raw) In-Reply-To: <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> On Tue, 20 Nov 2018 at 07:02, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > 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. > Are you saying user space may use names like "ctr-aes-neon" directly rather than "ctr(aes)" for any implementation of the mode? If so, that is highly unfortunate, since it means we'd be breaking user space by wrapping a crypto library function with its own arch specific specializations into a generic crypto API wrapper. Note that I think that using AF_ALG to access software crypto routines (as opposed to accelerators) is rather pointless to begin with, but if it permits that today than we're stuck with it. > 2. The arch-specific algorithm code lives in their own module rather > than in a monolithic module. > This is one of the remaining issues I have with Zinc. However, modulo the above concerns, I think it does make sense to have a separate function API for synchronous software routines below the current crypto API. What I don't want is a separate Zinc kingdom with a different name, different maintainers and going through a different tree, and with its own approach to test vectors, arch specific code, etc etc
next prev parent reply other threads:[~2018-11-20 21:00 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-05 23:25 [RFC PATCH v3 00/15] crypto: Adiantum support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 01/15] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 02/15] crypto: chacha20-generic - don't unnecessarily use atomic walk Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 03/15] crypto: chacha20-generic - add XChaCha20 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 04/15] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 05/15] crypto: chacha - add XChaCha12 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 06/15] crypto: arm/chacha20 - limit the preemption-disabled section Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 07/15] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-05 23:25 ` [RFC PATCH v3 08/15] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-05 23:25 ` [RFC PATCH v3 09/15] crypto: arm/chacha - add XChaCha12 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-12 18:58 ` Eric Biggers 2018-11-12 18:58 ` Eric Biggers 2018-11-12 18:58 ` Eric Biggers 2018-11-16 6:02 ` Herbert Xu 2018-11-16 6:02 ` Herbert Xu 2018-11-16 6:02 ` Herbert Xu 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-18 13:46 ` Jason A. Donenfeld 2018-11-18 13:46 ` Jason A. Donenfeld 2018-11-19 5:24 ` [RFC PATCH] zinc chacha20 generic implementation using crypto API code Herbert Xu 2018-11-19 6:13 ` Jason A. Donenfeld 2018-11-19 6:13 ` Jason A. Donenfeld 2018-11-19 6:22 ` Herbert Xu 2018-11-19 6:22 ` Herbert Xu 2018-11-19 22:54 ` Eric Biggers 2018-11-19 22:54 ` Eric Biggers 2018-11-19 23:15 ` Jason A. Donenfeld 2018-11-19 23:15 ` Jason A. Donenfeld 2018-11-19 23:23 ` Eric Biggers 2018-11-19 23:23 ` Eric Biggers 2018-11-19 23:31 ` Jason A. Donenfeld 2018-11-19 23:31 ` Jason A. Donenfeld 2018-11-20 3:06 ` Herbert Xu 2018-11-20 3:06 ` Herbert Xu 2018-11-20 3:08 ` Jason A. Donenfeld 2018-11-20 3:08 ` Jason A. Donenfeld 2018-11-20 6:02 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Herbert Xu 2018-11-20 6:02 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 1/4] crypto: chacha20 - Export chacha20 functions without crypto API Herbert Xu 2018-11-20 6:04 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 2/4] zinc: ChaCha20 generic C implementation and selftest Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 3/4] zinc: Add x86 accelerated ChaCha20 Herbert Xu 2018-11-20 6:04 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 4/4] zinc: ChaCha20 x86_64 implementation Herbert Xu 2018-11-20 10:32 ` Ard Biesheuvel [this message] 2018-11-20 10:32 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Ard Biesheuvel 2018-11-20 10:32 ` Ard Biesheuvel 2018-11-20 14:18 ` Herbert Xu 2018-11-20 14:18 ` Herbert Xu 2018-11-20 14:18 ` Herbert Xu 2018-11-20 16:24 ` Jason A. Donenfeld 2018-11-20 16:24 ` Jason A. Donenfeld 2018-11-20 18:51 ` Theodore Y. Ts'o 2018-11-20 18:51 ` Theodore Y. Ts'o 2018-11-21 7:55 ` Herbert Xu 2018-11-21 7:55 ` Herbert Xu 2018-11-20 16:18 ` Jason A. Donenfeld 2018-11-20 16:18 ` Jason A. Donenfeld 2018-11-21 6:01 ` Herbert Xu 2018-11-21 6:01 ` Herbert Xu 2018-11-05 23:25 ` [RFC PATCH v3 11/15] crypto: poly1305 - add Poly1305 core API Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 12/15] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 13/15] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 14/15] crypto: adiantum - add Adiantum support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 15/15] fscrypt: " Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-08 6:47 ` [RFC PATCH v3 00/15] crypto: " Martin Willi 2018-11-08 6:47 ` Martin Willi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKv+Gu-SHS2tF665dfqSgmH5EF5vGVtef=3_4WgCE=+8+Jw7Rw@mail.gmail.com' \ --to=ard.biesheuvel@linaro.org \ --cc=Jason@zx2c4.com \ --cc=ebiggers@kernel.org \ --cc=gkaiser@google.com \ --cc=herbert@gondor.apana.org.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=martin@strongswan.org \ --cc=paulcrowley@google.com \ --cc=samuel.c.p.neves@gmail.com \ --cc=tomer.ashur@esat.kuleuven.be \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.