Re: [PATCH 2/3] crypto: crypto_xor - use unaligned accessors for aligned fast path
Hi Ard,
On Mon, Oct 08, 2018 at 11:15:53PM +0200, Ard Biesheuvel wrote:
> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
> tolerate any misalignment of the memory address. However, load/store
> double and load/store multiple instructions (ldrd, ldm) may still only
> be used on memory addresses that are 32-bit aligned, and so we have to
> use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
> may end up with a severe performance hit due to alignment traps that
> require fixups by the kernel.
>
> Fortunately, the get_unaligned() accessors do the right thing: when
> building for ARMv6 or later, the compiler will emit unaligned accesses
> using the ordinary load/store instructions (but avoid the ones that
> require 32-bit alignment). When building for older ARM, those accessors
> will emit the appropriate sequence of ldrb/mov/orr instructions. And on
> architectures that can truly tolerate any kind of misalignment, the
> get_unaligned() accessors resolve to the leXX_to_cpup accessors that
> operate on aligned addresses.
>
> So switch to the unaligned accessors for the aligned fast path. This
> will create the exact same code on architectures that can really
> tolerate any kind of misalignment, and generate code for ARMv6+ that
> avoids load/store instructions that trigger alignment faults.
>
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/algapi.c | 7 +++
> include/crypto/algapi.h | 11 +--
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/crypto/algapi.c b/crypto/algapi.c
> index 2545c5f89c4c..52ce3c5a0499 100644
> --- a/crypto/algapi.c
> +++ b/crypto/algapi.c
> @@ -988,11 +988,10 @@ void crypto_inc(u8 *a, unsigned int size)
> __be32 *b = (__be32 *)(a + size);
> u32 c;
>
> - if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) ||
> - IS_ALIGNED((unsigned long)b, __alignof__(*b)))
> + if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS))
> for (; size >= 4; size -= 4) {
> - c = be32_to_cpu(*--b) + 1;
> - *b = cpu_to_be32(c);
> + c = get_unaligned_be32(--b) + 1;
> + put_unaligned_be32(c, b);
> if (likely(c))
> return;
> }
> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
> index 4a5ad10e75f0..86267c232f34 100644
> --- a/include/crypto/algapi.h
> +++ b/include/crypto/algapi.h
> @@ -17,6 +17,8 @@
> #include
> #include
>
> +#include
> +
> /*
> * Maximum values for blocksize and alignmask, used to allocate
> * static buffers that are big enough for any combination of
> @@ -212,7 +214,9 @@ static inline void crypto_xor(u8 *dst, const u8 *src,
> unsigned int size)
> unsigned long *s = (unsigned long *)src;
>
> while (size > 0) {
> - *d++ ^= *s++;
> + put_unaligned(get_unaligned(d) ^ get_unaligned(s), d);
> + d++;
> + s++;
> size -= sizeof(unsigned long);
> }
> } else {
> @@ -231,7 +235,10 @@ static inline void crypto_xor_cpy(u8 *dst, const u8
> *src1, const u8 *src2,
> unsigned long *s2 = (unsigned long *)src2;
>
> while (size > 0) {
> - *d++ = *s1++ ^ *s2++;
> + put_unaligned(get_unaligned(s1) ^ get_unaligned(s2), d);
> + d++;
> + s1++;
> + s2++;
> size -= sizeof(unsigned long);
> }
> } else {
> --
> 2.11.0
>
Doesn't __crypto_xor() have the same problem too?
- Eric
Re: [PATCH 1/3] crypto: memneq - use unaligned accessors for aligned fast path
Hi Ard,
On Mon, Oct 08, 2018 at 11:15:52PM +0200, Ard Biesheuvel wrote:
> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
> tolerate any misalignment of the memory address. However, load/store
> double and load/store multiple instructions (ldrd, ldm) may still only
> be used on memory addresses that are 32-bit aligned, and so we have to
> use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
> may end up with a severe performance hit due to alignment traps that
> require fixups by the kernel.
>
> Fortunately, the get_unaligned() accessors do the right thing: when
> building for ARMv6 or later, the compiler will emit unaligned accesses
> using the ordinary load/store instructions (but avoid the ones that
> require 32-bit alignment). When building for older ARM, those accessors
> will emit the appropriate sequence of ldrb/mov/orr instructions. And on
> architectures that can truly tolerate any kind of misalignment, the
> get_unaligned() accessors resolve to the leXX_to_cpup accessors that
> operate on aligned addresses.
>
> So switch to the unaligned accessors for the aligned fast path. This
> will create the exact same code on architectures that can really
> tolerate any kind of misalignment, and generate code for ARMv6+ that
> avoids load/store instructions that trigger alignment faults.
>
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/memneq.c | 24 ++--
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/crypto/memneq.c b/crypto/memneq.c
> index afed1bd16aee..0f46a6150f22 100644
> --- a/crypto/memneq.c
> +++ b/crypto/memneq.c
> @@ -60,6 +60,7 @@
> */
>
> #include
> +#include
>
> #ifndef __HAVE_ARCH_CRYPTO_MEMNEQ
>
> @@ -71,7 +72,10 @@ __crypto_memneq_generic(const void *a, const void *b,
> size_t size)
>
> #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> while (size >= sizeof(unsigned long)) {
> - neq |= *(unsigned long *)a ^ *(unsigned long *)b;
> + unsigned long const *p = a;
> + unsigned long const *q = b;
> +
> + neq |= get_unaligned(p) ^ get_unaligned(q);
> OPTIMIZER_HIDE_VAR(neq);
> a += sizeof(unsigned long);
> b += sizeof(unsigned long);
> @@ -95,18 +99,24 @@ static inline unsigned long __crypto_memneq_16(const void
> *a, const void *b)
>
> #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> if (sizeof(unsigned long) == 8) {
> - neq |= *(unsigned long *)(a) ^ *(unsigned long *)(b);
> + unsigned long const *p = a;
> + unsigned long const *q = b;
> +
> + neq |= get_unaligned(p++) ^ get_unaligned(q++);
> OPTIMIZER_HIDE_VAR(neq);
> - neq |= *(unsigned long *)(a+8) ^ *(unsigned long *)(b+8);
> + neq |= get_unaligned(p) ^ get_unaligned(q);
> OPTIMIZER_HIDE_VAR(neq);
> } else if (sizeof(unsigned int) == 4) {
> - neq |= *(unsigned int *)(a)^ *(unsigned int *)(b);
> + unsigned int const *p = a;
> + unsigned int const *q = b;
> +
> + neq |= get_unaligned(p++) ^ get_unaligned(q++);
> OPTIMIZER_HIDE_VAR(neq);
> - neq |= *(unsigned int *)(a+4) ^ *(unsigned int *)(b+4);
> + neq |= get_unaligned(p++) ^ get_unaligned(q++);
> OPTIMIZER_HIDE_VAR(neq);
> - neq |= *(unsigned int *)(a+8) ^ *(unsigned int *)(b+8);
> + neq |= get_unaligned(p++) ^ get_unaligned(q++);
> OPTIMIZER_HIDE_VAR(neq);
> - neq |= *(unsigned int *)(a+12) ^ *(unsigned int *)(b+12);
> + neq |= get_unaligned(p) ^ get_unaligned(q);
> OPTIMIZER_HIDE_VAR(neq);
> } else
> #endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
This looks good, but maybe now we should get rid of the
!CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS path too?
At least for the 16-byte case:
static inline unsigned long __crypto_memneq_16(const void *a, const void *b)
{
const unsigned long *p = a, *q = b;
unsigned long neq = 0;
BUILD_BUG_ON(sizeof(*p) != 4 && sizeof(*p) != 8);
neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
if (sizeof(*p) == 4) {
neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
}
return neq;
}
[PATCH 0/3] crypto: use unaligned accessors in aligned fast paths
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS behaves a bit counterintuitively on ARM: we set it for architecture revisions v6 and up, which support any alignment for load/store instructions that operate on bytes, half words or words. However, load/store double word and load store multiple instructions still require 32-bit alignment, and using them on unaligned quantities results in costly alignment traps that have to be fixed up by the kernel's fixup code. Fortunately, the unaligned accessors do the right thing here: on architectures that really tolerate any misalignment, they simply resolve to the aligned accessors, while on ARMv6+ (which uses the packed struct wrappers for unaligned accesses), they result in load/store sequences that avoid the instructions that require 32-bit alignment. Since there is not really a downside to using the unaligned accessors on aligned paths for architectures other than ARM that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, let's switch to them in a couple of places in the crypto code. Note that all patches are against code that has been observed to be emitted with ldm or ldrd instructions when building ARM's multi_v7_defconfig. Ard Biesheuvel (3): crypto: memneq - use unaligned accessors for aligned fast path crypto: crypto_xor - use unaligned accessors for aligned fast path crypto: siphash - drop _aligned variants crypto/algapi.c | 7 +- crypto/memneq.c | 24 +++-- include/crypto/algapi.h | 11 +- include/linux/siphash.h | 106 +--- lib/siphash.c | 103 ++- 5 files changed, 83 insertions(+), 168 deletions(-) -- 2.11.0
[PATCH 1/3] crypto: memneq - use unaligned accessors for aligned fast path
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory addresses that are 32-bit aligned, and so we have to
use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
may end up with a severe performance hit due to alignment traps that
require fixups by the kernel.
Fortunately, the get_unaligned() accessors do the right thing: when
building for ARMv6 or later, the compiler will emit unaligned accesses
using the ordinary load/store instructions (but avoid the ones that
require 32-bit alignment). When building for older ARM, those accessors
will emit the appropriate sequence of ldrb/mov/orr instructions. And on
architectures that can truly tolerate any kind of misalignment, the
get_unaligned() accessors resolve to the leXX_to_cpup accessors that
operate on aligned addresses.
So switch to the unaligned accessors for the aligned fast path. This
will create the exact same code on architectures that can really
tolerate any kind of misalignment, and generate code for ARMv6+ that
avoids load/store instructions that trigger alignment faults.
Signed-off-by: Ard Biesheuvel
---
crypto/memneq.c | 24 ++--
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/crypto/memneq.c b/crypto/memneq.c
index afed1bd16aee..0f46a6150f22 100644
--- a/crypto/memneq.c
+++ b/crypto/memneq.c
@@ -60,6 +60,7 @@
*/
#include
+#include
#ifndef __HAVE_ARCH_CRYPTO_MEMNEQ
@@ -71,7 +72,10 @@ __crypto_memneq_generic(const void *a, const void *b, size_t
size)
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
while (size >= sizeof(unsigned long)) {
- neq |= *(unsigned long *)a ^ *(unsigned long *)b;
+ unsigned long const *p = a;
+ unsigned long const *q = b;
+
+ neq |= get_unaligned(p) ^ get_unaligned(q);
OPTIMIZER_HIDE_VAR(neq);
a += sizeof(unsigned long);
b += sizeof(unsigned long);
@@ -95,18 +99,24 @@ static inline unsigned long __crypto_memneq_16(const void
*a, const void *b)
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
if (sizeof(unsigned long) == 8) {
- neq |= *(unsigned long *)(a) ^ *(unsigned long *)(b);
+ unsigned long const *p = a;
+ unsigned long const *q = b;
+
+ neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
- neq |= *(unsigned long *)(a+8) ^ *(unsigned long *)(b+8);
+ neq |= get_unaligned(p) ^ get_unaligned(q);
OPTIMIZER_HIDE_VAR(neq);
} else if (sizeof(unsigned int) == 4) {
- neq |= *(unsigned int *)(a)^ *(unsigned int *)(b);
+ unsigned int const *p = a;
+ unsigned int const *q = b;
+
+ neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
- neq |= *(unsigned int *)(a+4) ^ *(unsigned int *)(b+4);
+ neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
- neq |= *(unsigned int *)(a+8) ^ *(unsigned int *)(b+8);
+ neq |= get_unaligned(p++) ^ get_unaligned(q++);
OPTIMIZER_HIDE_VAR(neq);
- neq |= *(unsigned int *)(a+12) ^ *(unsigned int *)(b+12);
+ neq |= get_unaligned(p) ^ get_unaligned(q);
OPTIMIZER_HIDE_VAR(neq);
} else
#endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
--
2.11.0
[PATCH 2/3] crypto: crypto_xor - use unaligned accessors for aligned fast path
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory addresses that are 32-bit aligned, and so we have to
use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
may end up with a severe performance hit due to alignment traps that
require fixups by the kernel.
Fortunately, the get_unaligned() accessors do the right thing: when
building for ARMv6 or later, the compiler will emit unaligned accesses
using the ordinary load/store instructions (but avoid the ones that
require 32-bit alignment). When building for older ARM, those accessors
will emit the appropriate sequence of ldrb/mov/orr instructions. And on
architectures that can truly tolerate any kind of misalignment, the
get_unaligned() accessors resolve to the leXX_to_cpup accessors that
operate on aligned addresses.
So switch to the unaligned accessors for the aligned fast path. This
will create the exact same code on architectures that can really
tolerate any kind of misalignment, and generate code for ARMv6+ that
avoids load/store instructions that trigger alignment faults.
Signed-off-by: Ard Biesheuvel
---
crypto/algapi.c | 7 +++
include/crypto/algapi.h | 11 +--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 2545c5f89c4c..52ce3c5a0499 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -988,11 +988,10 @@ void crypto_inc(u8 *a, unsigned int size)
__be32 *b = (__be32 *)(a + size);
u32 c;
- if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) ||
- IS_ALIGNED((unsigned long)b, __alignof__(*b)))
+ if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS))
for (; size >= 4; size -= 4) {
- c = be32_to_cpu(*--b) + 1;
- *b = cpu_to_be32(c);
+ c = get_unaligned_be32(--b) + 1;
+ put_unaligned_be32(c, b);
if (likely(c))
return;
}
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 4a5ad10e75f0..86267c232f34 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -17,6 +17,8 @@
#include
#include
+#include
+
/*
* Maximum values for blocksize and alignmask, used to allocate
* static buffers that are big enough for any combination of
@@ -212,7 +214,9 @@ static inline void crypto_xor(u8 *dst, const u8 *src,
unsigned int size)
unsigned long *s = (unsigned long *)src;
while (size > 0) {
- *d++ ^= *s++;
+ put_unaligned(get_unaligned(d) ^ get_unaligned(s), d);
+ d++;
+ s++;
size -= sizeof(unsigned long);
}
} else {
@@ -231,7 +235,10 @@ static inline void crypto_xor_cpy(u8 *dst, const u8 *src1,
const u8 *src2,
unsigned long *s2 = (unsigned long *)src2;
while (size > 0) {
- *d++ = *s1++ ^ *s2++;
+ put_unaligned(get_unaligned(s1) ^ get_unaligned(s2), d);
+ d++;
+ s1++;
+ s2++;
size -= sizeof(unsigned long);
}
} else {
--
2.11.0
[PATCH 3/3] crypto: siphash - drop _aligned variants
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory addresses that are 32-bit aligned, and so we have to
use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
may end up with a severe performance hit due to alignment traps that
require fixups by the kernel.
Fortunately, the get_unaligned() accessors do the right thing: when
building for ARMv6 or later, the compiler will emit unaligned accesses
using the ordinary load/store instructions (but avoid the ones that
require 32-bit alignment). When building for older ARM, those accessors
will emit the appropriate sequence of ldrb/mov/orr instructions. And on
architectures that can truly tolerate any kind of misalignment, the
get_unaligned() accessors resolve to the leXX_to_cpup accessors that
operate on aligned addresses.
Since the compiler will in fact emit ldrd or ldm instructions when
building this code for ARM v6 or later, the solution is to use the
unaligned accessors on the aligned code paths. Given the above, this
either produces the same code, or better in the ARMv6+ case. However,
since that removes the only difference between the aligned and unaligned
variants, we can drop the aligned variant entirely.
Signed-off-by: Ard Biesheuvel
---
include/linux/siphash.h | 106 +---
lib/siphash.c | 103 ++-
2 files changed, 54 insertions(+), 155 deletions(-)
diff --git a/include/linux/siphash.h b/include/linux/siphash.h
index fa7a6b9cedbf..ef3c36b0ae0f 100644
--- a/include/linux/siphash.h
+++ b/include/linux/siphash.h
@@ -15,16 +15,14 @@
#include
#include
+#include
#define SIPHASH_ALIGNMENT __alignof__(u64)
typedef struct {
u64 key[2];
} siphash_key_t;
-u64 __siphash_aligned(const void *data, size_t len, const siphash_key_t *key);
-#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-u64 __siphash_unaligned(const void *data, size_t len, const siphash_key_t
*key);
-#endif
+u64 __siphash(const void *data, size_t len, const siphash_key_t *key);
u64 siphash_1u64(const u64 a, const siphash_key_t *key);
u64 siphash_2u64(const u64 a, const u64 b, const siphash_key_t *key);
@@ -48,26 +46,6 @@ static inline u64 siphash_4u32(const u32 a, const u32 b,
const u32 c,
}
-static inline u64 ___siphash_aligned(const __le64 *data, size_t len,
-const siphash_key_t *key)
-{
- if (__builtin_constant_p(len) && len == 4)
- return siphash_1u32(le32_to_cpup((const __le32 *)data), key);
- if (__builtin_constant_p(len) && len == 8)
- return siphash_1u64(le64_to_cpu(data[0]), key);
- if (__builtin_constant_p(len) && len == 16)
- return siphash_2u64(le64_to_cpu(data[0]), le64_to_cpu(data[1]),
- key);
- if (__builtin_constant_p(len) && len == 24)
- return siphash_3u64(le64_to_cpu(data[0]), le64_to_cpu(data[1]),
- le64_to_cpu(data[2]), key);
- if (__builtin_constant_p(len) && len == 32)
- return siphash_4u64(le64_to_cpu(data[0]), le64_to_cpu(data[1]),
- le64_to_cpu(data[2]), le64_to_cpu(data[3]),
- key);
- return __siphash_aligned(data, len, key);
-}
-
/**
* siphash - compute 64-bit siphash PRF value
* @data: buffer to hash
@@ -77,11 +55,30 @@ static inline u64 ___siphash_aligned(const __le64 *data,
size_t len,
static inline u64 siphash(const void *data, size_t len,
const siphash_key_t *key)
{
-#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
- if (!IS_ALIGNED((unsigned long)data, SIPHASH_ALIGNMENT))
- return __siphash_unaligned(data, len, key);
-#endif
- return ___siphash_aligned(data, len, key);
+ if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) {
+ if (__builtin_constant_p(len) && len == 4)
+ return siphash_1u32(get_unaligned_le32(data),
+ key);
+ if (__builtin_constant_p(len) && len == 8)
+ return siphash_1u64(get_unaligned_le64(data),
+ key);
+ if (__builtin_constant_p(len) && len == 16)
+ return siphash_2u64(get_unaligned_le64(data),
+ get_unaligned_le64(data + 8),
+ key);
+ if (__builtin_constant_p(len) && len == 24)
+ return siphash_3u64(get_unaligned_le64(data),
+ get_unaligned_le64(data + 8),
+ get_unaligned_le64(data + 16),
+
[PATCH] crypto: arm64/aes-blk - ensure XTS mask is always loaded
Commit 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
optimized away some reloads of the XTS mask vector, but failed to take
into account that calls into the XTS en/decrypt routines will take a
slightly different code path if a single block of input is split across
different buffers. So let's ensure that the first load occurs
unconditionally, and move the reload to the end so it doesn't occur
needlessly.
Fixes: 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-modes.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index 039738ae23f6..67700045a0e0 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -359,18 +359,17 @@ AES_ENTRY(aes_xts_encrypt)
mov x29, sp
ld1 {v4.16b}, [x6]
+ xts_load_mask v8
cbz w7, .Lxtsencnotfirst
enc_prepare w3, x5, x8
encrypt_block v4, w3, x5, x8, w7 /* first tweak */
enc_switch_key w3, x2, x8
- xts_load_mask v8
b .LxtsencNx
.Lxtsencnotfirst:
enc_prepare w3, x2, x8
.LxtsencloopNx:
- xts_reload_mask v8
next_tweak v4, v4, v8
.LxtsencNx:
subsw4, w4, #4
@@ -391,6 +390,7 @@ AES_ENTRY(aes_xts_encrypt)
st1 {v0.16b-v3.16b}, [x0], #64
mov v4.16b, v7.16b
cbz w4, .Lxtsencout
+ xts_reload_mask v8
b .LxtsencloopNx
.Lxtsenc1x:
addsw4, w4, #4
@@ -417,18 +417,17 @@ AES_ENTRY(aes_xts_decrypt)
mov x29, sp
ld1 {v4.16b}, [x6]
+ xts_load_mask v8
cbz w7, .Lxtsdecnotfirst
enc_prepare w3, x5, x8
encrypt_block v4, w3, x5, x8, w7 /* first tweak */
dec_prepare w3, x2, x8
- xts_load_mask v8
b .LxtsdecNx
.Lxtsdecnotfirst:
dec_prepare w3, x2, x8
.LxtsdecloopNx:
- xts_reload_mask v8
next_tweak v4, v4, v8
.LxtsdecNx:
subsw4, w4, #4
@@ -449,6 +448,7 @@ AES_ENTRY(aes_xts_decrypt)
st1 {v0.16b-v3.16b}, [x0], #64
mov v4.16b, v7.16b
cbz w4, .Lxtsdecout
+ xts_reload_mask v8
b .LxtsdecloopNx
.Lxtsdec1x:
addsw4, w4, #4
--
2.11.0
