All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, will.deacon@arm.com,
	nico@linaro.org
Subject: Re: [RFC PATCH] arm64: add support for AES in CCM mode using Crypto Extensions
Date: Tue, 25 Feb 2014 15:02:52 +0800	[thread overview]
Message-ID: <20140225070252.GB9934@gondor.apana.org.au> (raw)
In-Reply-To: <1392106905-28709-1-git-send-email-ard.biesheuvel@linaro.org>

On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
> This adds support for a synchronous implementation of AES in CCM mode
> using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> Hi all,
> 
> I am posting this for review/RFC. The main topic for feedback is the way
> I have used an inner blkcipher instance to process the encrypted + authenticated
> data.
> 
> The point of having a dedicated module for synchronous ccm(aes) is the fact that
> mac80211 uses it for WPA2 CCMP en-/decryption, where it runs entirely in soft
> IRQ context. In this case, the performance improvement offered by dedicated AES
> instructions is likely wasted on stacking and unstacking the NEON register file,
> as the generic CCM operates on a single AES block at a time.
> 
> Instead, this implementation interleaves the CTR and CBC modes at the round
> level, eliminating 50% of both the input and round key loads and (hopefully)
> eliminating pipeline stalls by operating on two AES blocks at a time.
> 
> Tested with tcrypt, no performance numbers yet.

I think your idea definitely make sense, since we do the same
thing in aesni-intel.

It'll be interesting to see some numbers, especially if we could
compare this against the generic version that we talked about
earlier.

Thanks,
-- 
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] arm64: add support for AES in CCM mode using Crypto Extensions
Date: Tue, 25 Feb 2014 15:02:52 +0800	[thread overview]
Message-ID: <20140225070252.GB9934@gondor.apana.org.au> (raw)
In-Reply-To: <1392106905-28709-1-git-send-email-ard.biesheuvel@linaro.org>

On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
> This adds support for a synchronous implementation of AES in CCM mode
> using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> Hi all,
> 
> I am posting this for review/RFC. The main topic for feedback is the way
> I have used an inner blkcipher instance to process the encrypted + authenticated
> data.
> 
> The point of having a dedicated module for synchronous ccm(aes) is the fact that
> mac80211 uses it for WPA2 CCMP en-/decryption, where it runs entirely in soft
> IRQ context. In this case, the performance improvement offered by dedicated AES
> instructions is likely wasted on stacking and unstacking the NEON register file,
> as the generic CCM operates on a single AES block at a time.
> 
> Instead, this implementation interleaves the CTR and CBC modes at the round
> level, eliminating 50% of both the input and round key loads and (hopefully)
> eliminating pipeline stalls by operating on two AES blocks at a time.
> 
> Tested with tcrypt, no performance numbers yet.

I think your idea definitely make sense, since we do the same
thing in aesni-intel.

It'll be interesting to see some numbers, especially if we could
compare this against the generic version that we talked about
earlier.

Thanks,
-- 
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

  reply	other threads:[~2014-02-25  7:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11  8:21 [RFC PATCH] arm64: add support for AES in CCM mode using Crypto Extensions Ard Biesheuvel
2014-02-11  8:21 ` Ard Biesheuvel
2014-02-25  7:02 ` Herbert Xu [this message]
2014-02-25  7:02   ` Herbert Xu
2014-02-25  7:12   ` Ard Biesheuvel
2014-02-25  7:12     ` Ard Biesheuvel
2014-02-25  7:16     ` Herbert Xu
2014-02-25  7:16       ` Herbert Xu
2014-02-25  7:21       ` Ard Biesheuvel
2014-02-25  7:21         ` Ard Biesheuvel
2014-02-25  9:08         ` Herbert Xu
2014-02-25  9:08           ` Herbert Xu
2014-02-25 10:11           ` Ard Biesheuvel
2014-02-25 10:11             ` 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=20140225070252.GB9934@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=nico@linaro.org \
    --cc=will.deacon@arm.com \
    /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.