All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	herbert@gondor.apana.org.au, will@kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH v6 5/6] crypto: arm64/aes-ccm - reduce NEON begin/end calls for common case
Date: Wed, 26 May 2021 20:08:05 +0200	[thread overview]
Message-ID: <CAMj1kXFKPB12QtP__7ANN5n-SFvmrskoCN2zwe-pXD_0HPrnBQ@mail.gmail.com> (raw)
In-Reply-To: <YK6B4PDchHbXNx3U@gmail.com>

On Wed, 26 May 2021 at 19:14, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, May 26, 2021 at 12:07:28PM +0200, Ard Biesheuvel wrote:
> > AES-CCM (as used in WPA2 CCMP, for instance) typically involves
> > authenticate-only data, and operates on a single network packet, and so
> > the common case is for the authenticate, en/decrypt and finalize SIMD
> > helpers to all be called exactly once in sequence. Since
> > kernel_neon_end() now involves manipulation of the preemption state as
> > well as the softirq mask state, let's reduce the number of times we are
> > forced to call it to only once if we are handling this common case.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/arm64/crypto/aes-ce-ccm-core.S |  1 +
> >  arch/arm64/crypto/aes-ce-ccm-glue.c | 74 +++++++++++---------
> >  2 files changed, 43 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
> > index 99a028e298ed..8adff299fcd3 100644
> > --- a/arch/arm64/crypto/aes-ce-ccm-core.S
> > +++ b/arch/arm64/crypto/aes-ce-ccm-core.S
> > @@ -124,6 +124,7 @@ SYM_FUNC_START(ce_aes_ccm_final)
> >  SYM_FUNC_END(ce_aes_ccm_final)
> >
> >       .macro  aes_ccm_do_crypt,enc
> > +     cbz     x2, 5f
> >       ldr     x8, [x6, #8]                    /* load lower ctr */
> >       ld1     {v0.16b}, [x5]                  /* load mac */
> >  CPU_LE(      rev     x8, x8                  )       /* keep swabbed ctr in reg */
> > diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
> > index 54bd2494a000..98159f2c49ae 100644
> > --- a/arch/arm64/crypto/aes-ce-ccm-glue.c
> > +++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
> > @@ -97,10 +97,8 @@ static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
> >  static void ccm_update_mac(struct crypto_aes_ctx *key, u8 mac[], u8 const in[],
> >                          u32 abytes, u32 *macp)
> >  {
> > -     kernel_neon_begin();
> >       ce_aes_ccm_auth_data(mac, in, abytes, macp, key->key_enc,
> >                            num_rounds(key));
> > -     kernel_neon_end();
> >  }
> [...]
> > +     if (req->assoclen)
> > +             ccm_calculate_auth_mac(req, mac);
> > +
>
> This still makes all the associated data be processed under a single
> kernel_neon_begin() / kernel_neon_end() pair, even if there is a large amount of
> it.  Shouldn't it be limited to a reasonable amount at a time, like 4K?
> This sort of thing has been considered a bug before, e.g. see
> commit 706024a52c6 ("crypto: arch/lib - limit simd usage to 4k chunks").
>
> You could do the entire CCM operation under a single pair as long as there isn't
> more than 4K of associated data.
>

Good point. I'll add a separate patch for that.

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	 herbert@gondor.apana.org.au, will@kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH v6 5/6] crypto: arm64/aes-ccm - reduce NEON begin/end calls for common case
Date: Wed, 26 May 2021 20:08:05 +0200	[thread overview]
Message-ID: <CAMj1kXFKPB12QtP__7ANN5n-SFvmrskoCN2zwe-pXD_0HPrnBQ@mail.gmail.com> (raw)
In-Reply-To: <YK6B4PDchHbXNx3U@gmail.com>

On Wed, 26 May 2021 at 19:14, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, May 26, 2021 at 12:07:28PM +0200, Ard Biesheuvel wrote:
> > AES-CCM (as used in WPA2 CCMP, for instance) typically involves
> > authenticate-only data, and operates on a single network packet, and so
> > the common case is for the authenticate, en/decrypt and finalize SIMD
> > helpers to all be called exactly once in sequence. Since
> > kernel_neon_end() now involves manipulation of the preemption state as
> > well as the softirq mask state, let's reduce the number of times we are
> > forced to call it to only once if we are handling this common case.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/arm64/crypto/aes-ce-ccm-core.S |  1 +
> >  arch/arm64/crypto/aes-ce-ccm-glue.c | 74 +++++++++++---------
> >  2 files changed, 43 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
> > index 99a028e298ed..8adff299fcd3 100644
> > --- a/arch/arm64/crypto/aes-ce-ccm-core.S
> > +++ b/arch/arm64/crypto/aes-ce-ccm-core.S
> > @@ -124,6 +124,7 @@ SYM_FUNC_START(ce_aes_ccm_final)
> >  SYM_FUNC_END(ce_aes_ccm_final)
> >
> >       .macro  aes_ccm_do_crypt,enc
> > +     cbz     x2, 5f
> >       ldr     x8, [x6, #8]                    /* load lower ctr */
> >       ld1     {v0.16b}, [x5]                  /* load mac */
> >  CPU_LE(      rev     x8, x8                  )       /* keep swabbed ctr in reg */
> > diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
> > index 54bd2494a000..98159f2c49ae 100644
> > --- a/arch/arm64/crypto/aes-ce-ccm-glue.c
> > +++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
> > @@ -97,10 +97,8 @@ static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
> >  static void ccm_update_mac(struct crypto_aes_ctx *key, u8 mac[], u8 const in[],
> >                          u32 abytes, u32 *macp)
> >  {
> > -     kernel_neon_begin();
> >       ce_aes_ccm_auth_data(mac, in, abytes, macp, key->key_enc,
> >                            num_rounds(key));
> > -     kernel_neon_end();
> >  }
> [...]
> > +     if (req->assoclen)
> > +             ccm_calculate_auth_mac(req, mac);
> > +
>
> This still makes all the associated data be processed under a single
> kernel_neon_begin() / kernel_neon_end() pair, even if there is a large amount of
> it.  Shouldn't it be limited to a reasonable amount at a time, like 4K?
> This sort of thing has been considered a bug before, e.g. see
> commit 706024a52c6 ("crypto: arch/lib - limit simd usage to 4k chunks").
>
> You could do the entire CCM operation under a single pair as long as there isn't
> more than 4K of associated data.
>

Good point. I'll add a separate patch for that.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-26 18:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 10:07 [PATCH v6 0/6] running kernel mode SIMD with softirqs disabled Ard Biesheuvel
2021-05-26 10:07 ` Ard Biesheuvel
2021-05-26 10:07 ` [PATCH v6 1/6] crypto: arm64/gcm-aes-ce - remove non-SIMD fallback path Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 10:07 ` [PATCH v6 2/6] crypto: arm64/aes-neonbs - stop using SIMD helper for skciphers Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 10:07 ` [PATCH v6 3/6] crypto: arm64/aes-ce " Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 10:07 ` [PATCH v6 4/6] crypto: arm64/aes-ccm - remove non-SIMD fallback path Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 16:57   ` Eric Biggers
2021-05-26 16:57     ` Eric Biggers
2021-05-26 10:07 ` [PATCH v6 5/6] crypto: arm64/aes-ccm - reduce NEON begin/end calls for common case Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 17:14   ` Eric Biggers
2021-05-26 17:14     ` Eric Biggers
2021-05-26 18:08     ` Ard Biesheuvel [this message]
2021-05-26 18:08       ` Ard Biesheuvel
2021-05-26 10:07 ` [PATCH v6 6/6] crypto: arm64/aes-ccm - avoid by-ref argument for ce_aes_ccm_auth_data Ard Biesheuvel
2021-05-26 10:07   ` Ard Biesheuvel
2021-05-26 17:18   ` Eric Biggers
2021-05-26 17:18     ` Eric Biggers

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=CAMj1kXFKPB12QtP__7ANN5n-SFvmrskoCN2zwe-pXD_0HPrnBQ@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=will@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.