From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sat, 28 Feb 2015 23:31:04 +0100 (CET) Received: by wghl18 with SMTP id l18so26678246wgh.7 for ; Sat, 28 Feb 2015 14:31:02 -0800 (PST) Message-ID: <54F241A1.1060104@gmail.com> Date: Sat, 28 Feb 2015 23:30:57 +0100 From: Milan Broz MIME-Version: 1.0 References: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org> In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ard Biesheuvel , linux@arm.linux.org.uk, herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: dm-crypt , Johannes Ernst , nico@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 > Signed-off-by: Ard Biesheuvel > --- > > 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 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version Date: Sat, 28 Feb 2015 23:30:57 +0100 Message-ID: <54F241A1.1060104@gmail.com> References: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: dm-crypt , Johannes Ernst , nico-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org To: Ard Biesheuvel , 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 Return-path: In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dm-crypt-bounces-4q3lyFh4P1g@public.gmane.org Sender: "dm-crypt" List-Id: linux-crypto.vger.kernel.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 > Signed-off-by: Ard Biesheuvel > --- > > 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: gmazyland@gmail.com (Milan Broz) Date: Sat, 28 Feb 2015 23:30:57 +0100 Subject: [PATCH] ARM: crypto: update NEON AES module to latest OpenSSL version In-Reply-To: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org> References: <1424935325-14437-1-git-send-email-ard.biesheuvel@linaro.org> Message-ID: <54F241A1.1060104@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 > Signed-off-by: Ard Biesheuvel > --- > > 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 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 >