All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	LKML <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: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc
Date: Tue, 20 Nov 2018 14:02:17 +0800	[thread overview]
Message-ID: <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> (raw)
In-Reply-To: <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au>

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: herbert@gondor.apana.org.au (Herbert Xu)
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 14:02:17 +0800	[thread overview]
Message-ID: <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> (raw)
In-Reply-To: <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au>

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  parent reply	other threads:[~2018-11-20 16:29 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               ` Herbert Xu [this message]
2018-11-20  6:02                 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc 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                 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Ard Biesheuvel
2018-11-20 10:32                   ` 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=20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=Jason@zx2c4.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ebiggers@kernel.org \
    --cc=gkaiser@google.com \
    --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: link
Be 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.