From: Milan Broz <gmazyland@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux@arm.linux.org.uk, herbert@gondor.apana.org.au,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dm-crypt <dm-crypt@saout.de>,
Johannes Ernst <johannes.ernst@gmail.com>,
nico@linaro.org
Subject: Re: [dm-crypt] [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version
Date: Sat, 28 Feb 2015 23:30:57 +0100 [thread overview]
Message-ID: <54F241A1.1060104@gmail.com> (raw)
In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org>
On 02/26/2015 08:22 AM, Ard Biesheuvel wrote:
> This updates the bit sliced AES module to the latest version in the
> upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a
> bug in the XTS decryption path, where data chunked in a certain way
> could trigger the ciphertext stealing code, which is not supposed to
> be active in the kernel build (The kernel implementation of XTS only
> supports round multiples of the AES block size of 16 bytes, whereas
> the conformant OpenSSL implementation of XTS supports inputs of
> arbitrary size by applying ciphertext stealing). This is fixed in
> the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
> around the offending instructions.
>
> The upstream code also contains the change applied by Russell to
> build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
> but implemented slightly differently.
>
> Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
> Reported-by: Adrian Kotelba <adrian.kotelba@gmail.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> This was found using the tcrypt test code, to which I recently added additional
> chunking modes. However, XTS typically operates on pages or at least on sectors,
> so this bug is unlikely to affect anyone in real life.
>
> Still, please add cc stable when applying,
Please apply it for stable.
For me, this patch fixed bug reported here
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7966
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13102.html
Cryptsetup uses AF_ALG userspace crypto SKCIPHER interface and on
Raspberry Pi2 with Neon AES implementation it fails to unlock LUKS device
(if XTS and aes-arm-bs module is used).
After applying this patch it works as expected.
I did not have time to check it more in detail (we are always encrypting
the whole sector so this should not happen... but apparently it does.)
Tested-by: Milan Broz <gmazyland@gmail.com>
Thanks,
Milan
>
> Thanks,
> Ard.
>
>
> arch/arm/crypto/aesbs-core.S_shipped | 12 ++++++++----
> arch/arm/crypto/bsaes-armv7.pl | 12 ++++++++----
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/crypto/aesbs-core.S_shipped b/arch/arm/crypto/aesbs-core.S_shipped
> index 71e5fc7cfb18..1d1800f71c5b 100644
> --- a/arch/arm/crypto/aesbs-core.S_shipped
> +++ b/arch/arm/crypto/aesbs-core.S_shipped
> @@ -58,14 +58,18 @@
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -74,8 +78,6 @@
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2095,9 +2097,11 @@ bsaes_xts_decrypt:
> vld1.8 {q8}, [r0] @ initial tweak
> adr r2, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst r9, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne r9, #0x10 @ subtract another 16 bytes
> +#endif
> subs r9, #0x80
>
> blo .Lxts_dec_short
> diff --git a/arch/arm/crypto/bsaes-armv7.pl b/arch/arm/crypto/bsaes-armv7.pl
> index be068db960ee..a4d3856e7d24 100644
> --- a/arch/arm/crypto/bsaes-armv7.pl
> +++ b/arch/arm/crypto/bsaes-armv7.pl
> @@ -701,14 +701,18 @@ $code.=<<___;
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -717,8 +721,6 @@ $code.=<<___;
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2076,9 +2078,11 @@ bsaes_xts_decrypt:
> vld1.8 {@XMM[8]}, [r0] @ initial tweak
> adr $magic, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst $len, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne $len, #0x10 @ subtract another 16 bytes
> +#endif
> subs $len, #0x80
>
> blo .Lxts_dec_short
>
WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: dm-crypt <dm-crypt-4q3lyFh4P1g@public.gmane.org>,
Johannes Ernst
<johannes.ernst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
nico-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version
Date: Sat, 28 Feb 2015 23:30:57 +0100 [thread overview]
Message-ID: <54F241A1.1060104@gmail.com> (raw)
In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 02/26/2015 08:22 AM, Ard Biesheuvel wrote:
> This updates the bit sliced AES module to the latest version in the
> upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a
> bug in the XTS decryption path, where data chunked in a certain way
> could trigger the ciphertext stealing code, which is not supposed to
> be active in the kernel build (The kernel implementation of XTS only
> supports round multiples of the AES block size of 16 bytes, whereas
> the conformant OpenSSL implementation of XTS supports inputs of
> arbitrary size by applying ciphertext stealing). This is fixed in
> the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
> around the offending instructions.
>
> The upstream code also contains the change applied by Russell to
> build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
> but implemented slightly differently.
>
> Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
> Reported-by: Adrian Kotelba <adrian.kotelba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> This was found using the tcrypt test code, to which I recently added additional
> chunking modes. However, XTS typically operates on pages or at least on sectors,
> so this bug is unlikely to affect anyone in real life.
>
> Still, please add cc stable when applying,
Please apply it for stable.
For me, this patch fixed bug reported here
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7966
http://www.mail-archive.com/linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg13102.html
Cryptsetup uses AF_ALG userspace crypto SKCIPHER interface and on
Raspberry Pi2 with Neon AES implementation it fails to unlock LUKS device
(if XTS and aes-arm-bs module is used).
After applying this patch it works as expected.
I did not have time to check it more in detail (we are always encrypting
the whole sector so this should not happen... but apparently it does.)
Tested-by: Milan Broz <gmazyland-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks,
Milan
>
> Thanks,
> Ard.
>
>
> arch/arm/crypto/aesbs-core.S_shipped | 12 ++++++++----
> arch/arm/crypto/bsaes-armv7.pl | 12 ++++++++----
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/crypto/aesbs-core.S_shipped b/arch/arm/crypto/aesbs-core.S_shipped
> index 71e5fc7cfb18..1d1800f71c5b 100644
> --- a/arch/arm/crypto/aesbs-core.S_shipped
> +++ b/arch/arm/crypto/aesbs-core.S_shipped
> @@ -58,14 +58,18 @@
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -74,8 +78,6 @@
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2095,9 +2097,11 @@ bsaes_xts_decrypt:
> vld1.8 {q8}, [r0] @ initial tweak
> adr r2, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst r9, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne r9, #0x10 @ subtract another 16 bytes
> +#endif
> subs r9, #0x80
>
> blo .Lxts_dec_short
> diff --git a/arch/arm/crypto/bsaes-armv7.pl b/arch/arm/crypto/bsaes-armv7.pl
> index be068db960ee..a4d3856e7d24 100644
> --- a/arch/arm/crypto/bsaes-armv7.pl
> +++ b/arch/arm/crypto/bsaes-armv7.pl
> @@ -701,14 +701,18 @@ $code.=<<___;
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -717,8 +721,6 @@ $code.=<<___;
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2076,9 +2078,11 @@ bsaes_xts_decrypt:
> vld1.8 {@XMM[8]}, [r0] @ initial tweak
> adr $magic, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst $len, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne $len, #0x10 @ subtract another 16 bytes
> +#endif
> subs $len, #0x80
>
> blo .Lxts_dec_short
>
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g@public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt
WARNING: multiple messages have this Message-ID (diff)
From: gmazyland@gmail.com (Milan Broz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version
Date: Sat, 28 Feb 2015 23:30:57 +0100 [thread overview]
Message-ID: <54F241A1.1060104@gmail.com> (raw)
In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org>
On 02/26/2015 08:22 AM, Ard Biesheuvel wrote:
> This updates the bit sliced AES module to the latest version in the
> upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a
> bug in the XTS decryption path, where data chunked in a certain way
> could trigger the ciphertext stealing code, which is not supposed to
> be active in the kernel build (The kernel implementation of XTS only
> supports round multiples of the AES block size of 16 bytes, whereas
> the conformant OpenSSL implementation of XTS supports inputs of
> arbitrary size by applying ciphertext stealing). This is fixed in
> the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
> around the offending instructions.
>
> The upstream code also contains the change applied by Russell to
> build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
> but implemented slightly differently.
>
> Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
> Reported-by: Adrian Kotelba <adrian.kotelba@gmail.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> This was found using the tcrypt test code, to which I recently added additional
> chunking modes. However, XTS typically operates on pages or at least on sectors,
> so this bug is unlikely to affect anyone in real life.
>
> Still, please add cc stable when applying,
Please apply it for stable.
For me, this patch fixed bug reported here
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7966
http://www.mail-archive.com/linux-crypto at vger.kernel.org/msg13102.html
Cryptsetup uses AF_ALG userspace crypto SKCIPHER interface and on
Raspberry Pi2 with Neon AES implementation it fails to unlock LUKS device
(if XTS and aes-arm-bs module is used).
After applying this patch it works as expected.
I did not have time to check it more in detail (we are always encrypting
the whole sector so this should not happen... but apparently it does.)
Tested-by: Milan Broz <gmazyland@gmail.com>
Thanks,
Milan
>
> Thanks,
> Ard.
>
>
> arch/arm/crypto/aesbs-core.S_shipped | 12 ++++++++----
> arch/arm/crypto/bsaes-armv7.pl | 12 ++++++++----
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/crypto/aesbs-core.S_shipped b/arch/arm/crypto/aesbs-core.S_shipped
> index 71e5fc7cfb18..1d1800f71c5b 100644
> --- a/arch/arm/crypto/aesbs-core.S_shipped
> +++ b/arch/arm/crypto/aesbs-core.S_shipped
> @@ -58,14 +58,18 @@
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -74,8 +78,6 @@
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2095,9 +2097,11 @@ bsaes_xts_decrypt:
> vld1.8 {q8}, [r0] @ initial tweak
> adr r2, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst r9, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne r9, #0x10 @ subtract another 16 bytes
> +#endif
> subs r9, #0x80
>
> blo .Lxts_dec_short
> diff --git a/arch/arm/crypto/bsaes-armv7.pl b/arch/arm/crypto/bsaes-armv7.pl
> index be068db960ee..a4d3856e7d24 100644
> --- a/arch/arm/crypto/bsaes-armv7.pl
> +++ b/arch/arm/crypto/bsaes-armv7.pl
> @@ -701,14 +701,18 @@ $code.=<<___;
> # define VFP_ABI_FRAME 0
> # define BSAES_ASM_EXTENDED_KEY
> # define XTS_CHAIN_TWEAK
> -# define __ARM_ARCH__ 7
> +# define __ARM_ARCH__ __LINUX_ARM_ARCH__
> +# define __ARM_MAX_ARCH__ 7
> #endif
>
> #ifdef __thumb__
> # define adrl adr
> #endif
>
> -#if __ARM_ARCH__>=7
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
> .text
> .syntax unified @ ARMv7-capable assembler is expected to handle this
> #ifdef __thumb2__
> @@ -717,8 +721,6 @@ $code.=<<___;
> .code 32
> #endif
>
> -.fpu neon
> -
> .type _bsaes_decrypt8,%function
> .align 4
> _bsaes_decrypt8:
> @@ -2076,9 +2078,11 @@ bsaes_xts_decrypt:
> vld1.8 {@XMM[8]}, [r0] @ initial tweak
> adr $magic, .Lxts_magic
>
> +#ifndef XTS_CHAIN_TWEAK
> tst $len, #0xf @ if not multiple of 16
> it ne @ Thumb2 thing, sanity check in ARM
> subne $len, #0x10 @ subtract another 16 bytes
> +#endif
> subs $len, #0x80
>
> blo .Lxts_dec_short
>
next prev parent reply other threads:[~2015-02-28 22:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 7:22 [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version Ard Biesheuvel
2015-02-26 7:22 ` Ard Biesheuvel
2015-02-28 22:30 ` Milan Broz [this message]
2015-02-28 22:30 ` Milan Broz
2015-02-28 22:30 ` Milan Broz
2015-03-02 8:26 ` [dm-crypt] " Ard Biesheuvel
2015-03-02 8:26 ` Ard Biesheuvel
2015-03-02 8:26 ` Ard Biesheuvel
2015-03-02 10:19 ` Herbert Xu
2015-03-02 10:19 ` Herbert Xu
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=54F241A1.1060104@gmail.com \
--to=gmazyland@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dm-crypt@saout.de \
--cc=herbert@gondor.apana.org.au \
--cc=johannes.ernst@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nico@linaro.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.