All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: [RFC PATCH 00/20] AES cleanup
Date: Wed, 12 Jun 2019 16:00:20 +0200	[thread overview]
Message-ID: <CAKv+Gu83M9_3DbAz9u_nmLs=4VL-BJh_L-FsEcFRAf4c2P=Gpw@mail.gmail.com> (raw)
In-Reply-To: <20190612135823.5w2dkibl4r7qcxx4@gondor.apana.org.au>

On Wed, 12 Jun 2019 at 15:58, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Wed, Jun 12, 2019 at 02:48:18PM +0200, Ard Biesheuvel wrote:
> >
> > All the patches leading up to that are cleanups for the AES code, to reduce
> > the dependency on the generic table based AES code, or in some cases, hardcoded
> > dependencies on the scalar arm64 asm code which suffers from the same problem.
> > It also removes redundant key expansion routines, and gets rid of the x86
> > scalar asm code, which is a maintenance burden and is not actually faster than
> > the generic code built with a modern compiler.
>
> Nice, I like this a lot.
>
> I presume you'll be converting the AES cipher users throughout
> the kernel (such as net/ipv4/tcp_fastopen) at some point, right?
>

Yes. I am currently surveying which users need to switch to a proper
mode, and which ones can just use the unoptimized library version
(such as tcp_fastopen).

  reply	other threads:[~2019-06-12 14:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-12 12:48 [RFC PATCH 00/20] AES cleanup Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 01/20] crypto: arm/aes-ce - cosmetic/whitespace cleanup Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 02/20] crypto: arm/aes - rename local routines to prevent future clashes Ard Biesheuvel
2019-06-12 15:23   ` Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 03/20] crypto: aes/fixed-time - align key schedule with other implementations Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 04/20] crypto: aes - create AES library based on the fixed time AES code Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 05/20] crypto: x86/aes-ni - switch to generic for fallback and key routines Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 06/20] crypto: x86/aes - drop scalar assembler implementations Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 07/20] crypto: padlock/aes - switch to library version of key expansion routine Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 08/20] crypto: cesa/aes " Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 09/20] crypto: safexcel/aes " Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 10/20] crypto: arm64/ghash - switch to AES library Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 11/20] crypto: arm/aes-neonbs - switch to library version of key expansion routine Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 12/20] crypto: arm64/aes-ccm - switch to AES library Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 13/20] crypto: arm64/aes-neonbs - switch to library version of key expansion routine Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 14/20] crypto: arm64/aes-ce " Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 15/20] crypto: generic/aes - drop key expansion routine in favor of library version Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 16/20] crypto: arm64/aes-ce-cipher - use AES library as fallback Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 17/20] crypto: aes - move ctr(aes) non-SIMD fallback to AES library Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 18/20] crypto: arm/aes-ce - provide a synchronous version of ctr(aes) Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 19/20] crypto: arm/aes-neonbs " Ard Biesheuvel
2019-06-12 12:48 ` [RFC PATCH 20/20] crypto: arm/ghash - provide a synchronous version Ard Biesheuvel
2019-06-12 13:58 ` [RFC PATCH 00/20] AES cleanup Herbert Xu
2019-06-12 14:00   ` Ard Biesheuvel [this message]
2019-06-12 17:08     ` Ard Biesheuvel

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+Gu83M9_3DbAz9u_nmLs=4VL-BJh_L-FsEcFRAf4c2P=Gpw@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /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.