[GIT PULL] ARM: NEON accelerated AES

[GIT PULL] ARM: NEON accelerated AES

[Ard Biesheuvel]

!! NOTE !!: this series build-depends on patch a62b01cd (crypto: create generic
version of ablk_helper) which is in linux-next but not yet in mainline.

The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6:

  Linux 3.12-rc3 (2013-09-29 15:02:38 -0700)

are available in the git repository at:

  git://git.linaro.org/people/ardbiesheuvel/linux-arm.git arm-aesbs

for you to fetch changes up to e4e7f10bfc4069925e99cc4b428c3434e30b6c3f:

  ARM: add support for bit sliced AES using NEON instructions (2013-10-04 20:48:38 +0200)

----------------------------------------------------------------
Ard Biesheuvel (3):
      ARM: pull in <asm/simd.h> from asm-generic
      ARM: move AES typedefs and function prototypes to separate header
      ARM: add support for bit sliced AES using NEON instructions

 arch/arm/crypto/Makefile             |   14 +-
 arch/arm/crypto/aes_glue.c           |   22 +-
 arch/arm/crypto/aes_glue.h           |   19 +
 arch/arm/crypto/aesbs-core.S_shipped | 2544 ++++++++++++++++++++++++++++++++++
 arch/arm/crypto/aesbs-glue.c         |  434 ++++++
 arch/arm/crypto/bsaes-armv7.pl       | 2467 +++++++++++++++++++++++++++++++++
 arch/arm/include/asm/Kbuild          |    1 +
 crypto/Kconfig                       |   16 +
 8 files changed, 5499 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/crypto/aes_glue.h
 create mode 100644 arch/arm/crypto/aesbs-core.S_shipped
 create mode 100644 arch/arm/crypto/aesbs-glue.c
 create mode 100644 arch/arm/crypto/bsaes-armv7.pl

[GIT PULL] ARM: NEON accelerated AES

[Dave Martin]

On Mon, Oct 07, 2013 at 03:19:58PM +0200, Ard Biesheuvel wrote:
> !! NOTE !!: this series build-depends on patch a62b01cd (crypto: create generic
> version of ablk_helper) which is in linux-next but not yet in mainline.
> 
> The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6:
> 
>   Linux 3.12-rc3 (2013-09-29 15:02:38 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/ardbiesheuvel/linux-arm.git arm-aesbs
> 
> for you to fetch changes up to e4e7f10bfc4069925e99cc4b428c3434e30b6c3f:
> 
>   ARM: add support for bit sliced AES using NEON instructions (2013-10-04 20:48:38 +0200)

Since nobody has stepped up to review this in detail, it appears there
may be nobody on the relvant lists who is sufficiently expert in AES and
NEON/v8 to review it.

To trust the openssl community on this doubtless makes sense (I notice
that, by an astonishing coincidence, the relevant changes to that project
have been made a certain Ard Biesheuvel).

How do you propose this code should be maintained in the kernel?

Adding a script which automatically diffs the files in the kernel
against openssl might be a good idea -- not every time the kernel is
built, but as a maintainer activity someone can script up.  This has the
advantage that ordinary kernel developers will be able to comprehend,
review, and use it, unlike the AES code itself.

Otherwise, important upstream fixes may not reach the kernel, or the
two codebases might diverge, especially if a significant code refactoring
occurs in openssl.  (I don't know whether that's likely or not)

Cheers
---Dave


> 
> ----------------------------------------------------------------
> Ard Biesheuvel (3):
>       ARM: pull in <asm/simd.h> from asm-generic
>       ARM: move AES typedefs and function prototypes to separate header
>       ARM: add support for bit sliced AES using NEON instructions
> 
>  arch/arm/crypto/Makefile             |   14 +-
>  arch/arm/crypto/aes_glue.c           |   22 +-
>  arch/arm/crypto/aes_glue.h           |   19 +
>  arch/arm/crypto/aesbs-core.S_shipped | 2544 ++++++++++++++++++++++++++++++++++
>  arch/arm/crypto/aesbs-glue.c         |  434 ++++++
>  arch/arm/crypto/bsaes-armv7.pl       | 2467 +++++++++++++++++++++++++++++++++
>  arch/arm/include/asm/Kbuild          |    1 +
>  crypto/Kconfig                       |   16 +
>  8 files changed, 5499 insertions(+), 18 deletions(-)
>  create mode 100644 arch/arm/crypto/aes_glue.h
>  create mode 100644 arch/arm/crypto/aesbs-core.S_shipped
>  create mode 100644 arch/arm/crypto/aesbs-glue.c
>  create mode 100644 arch/arm/crypto/bsaes-armv7.pl
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL] ARM: NEON accelerated AES

[Ard Biesheuvel]

On 7 October 2013 18:25, Dave Martin <Dave.Martin@arm.com> wrote:
> On Mon, Oct 07, 2013 at 03:19:58PM +0200, Ard Biesheuvel wrote:
>> !! NOTE !!: this series build-depends on patch a62b01cd (crypto: create generic
>> version of ablk_helper) which is in linux-next but not yet in mainline.
>>
>> The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6:
>>
>>   Linux 3.12-rc3 (2013-09-29 15:02:38 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.linaro.org/people/ardbiesheuvel/linux-arm.git arm-aesbs
>>
>> for you to fetch changes up to e4e7f10bfc4069925e99cc4b428c3434e30b6c3f:
>>
>>   ARM: add support for bit sliced AES using NEON instructions (2013-10-04 20:48:38 +0200)
>
> Since nobody has stepped up to review this in detail, it appears there
> may be nobody on the relvant lists who is sufficiently expert in AES and
> NEON/v8 to review it.
>

Well, I did receive (and implemented) a very useful suggestion from
Jussi Kivilinna on the linux-crypto list which resulted in a 25%
speedup in decryption, so some people did actually look at the code in
detail.
Note btw that this is v7 not v8, there is no v8 support yet in
OpenSSL. I have been hitting the list with v8 stuff as well, so I
understand the confusion.

> To trust the openssl community on this doubtless makes sense (I notice
> that, by an astonishing coincidence, the relevant changes to that project
> have been made a certain Ard Biesheuvel).
>
> How do you propose this code should be maintained in the kernel?
>

Well, I tried very hard to make this as little of a burden as possible
by putting all the kernel specific hooks in the upstream codebase. The
bsaes-armv7.pl in this series is identical to the upstream one, and
trying to keep it that way is our best bet imo.

Perhaps the more senior members in this community would like to
comment on how to proceed with keeping this in sync, as I am sure this
is not the first time code has been adopted from another open source
project. How does this work in general?

> Adding a script which automatically diffs the files in the kernel
> against openssl might be a good idea -- not every time the kernel is
> built, but as a maintainer activity someone can script up.  This has the
> advantage that ordinary kernel developers will be able to comprehend,
> review, and use it, unlike the AES code itself.
>
> Otherwise, important upstream fixes may not reach the kernel, or the
> two codebases might diverge, especially if a significant code refactoring
> occurs in openssl.  (I don't know whether that's likely or not)
>

Well, fortunately, the OpenSSL maintainer is very eager to keep his
code in sync, so I am sure he will notify me (and likely the list
and/or Russell as well) if he takes in any fixes. Let's reciprocate
and keep him in the loop if we spot any errors or other issues.

Regards,
Ard.