linux-toradex.git/arch/arm64/crypto, branch v4.4.136

crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes

2017-02-09T07:02:45+00:00

commit 11e3b725cfc282efe9d4a354153e99d86a16af08 upstream.

Update the ARMv8 Crypto Extensions and the plain NEON AES implementations
in CBC and CTR modes to return the next IV back to the skcipher API client.
This is necessary for chaining to work correctly.

Note that for CTR, this is only done if the request is a round multiple of
the block size, since otherwise, chaining is impossible anyway.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/aes-ce - fix for big endian

2017-01-12T10:22:50+00:00

commit 1803b9a52c4e5a5dbb8a27126f6bc06939359753 upstream.

The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.

Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/aes-xts-ce: fix for big endian

2017-01-12T10:22:50+00:00

commit caf4b9e2b326cc2a5005a5c557274306536ace61 upstream.

Emit the XTS tweak literal constants in the appropriate order for a
single 128-bit scalar literal load.

Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/sha1-ce - fix for big endian

2017-01-12T10:22:50+00:00

commit ee71e5f1e7d25543ee63a80451871f8985b8d431 upstream.

The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.

Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/aes-neon - fix for big endian

2017-01-12T10:22:50+00:00

commit a2c435cc99862fd3d165e1b66bf48ac72c839c62 upstream.

The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.

Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/aes-ccm-ce: fix for big endian

2017-01-12T10:22:50+00:00

commit 56e4e76c68fcb51547b5299e5b66a135935ff414 upstream.

The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.

Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/ghash-ce - fix for big endian

2017-01-12T10:22:50+00:00

commit 9c433ad5083fd4a4a3c721d86cbfbd0b2a2326a5 upstream.

The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.

Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/sha2-ce - fix for big endian

2017-01-12T10:22:49+00:00

commit 174122c39c369ed924d2608fc0be0171997ce800 upstream.

The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.

Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: arm64/aes-ctr - fix NULL dereference in tail processing

2016-09-30T08:18:34+00:00

commit 2db34e78f126c6001d79d3b66ab1abb482dc7caa upstream.

The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.

However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes > 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.

Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Reported-by: xiakaixu 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

arm64: crypto: reduce priority of core AES cipher

2015-11-18T12:09:08+00:00

The asynchronous, merged implementations of AES in CBC, CTR and XTS
modes are preferred when available (i.e., when instantiating ablkciphers
explicitly). However, the synchronous core AES cipher combined with the
generic CBC mode implementation will produce a 'cbc(aes)' blkcipher that
is callable asynchronously as well. To prevent this implementation from
being used when the accelerated asynchronous implemenation is also
available, lower its priority to 250 (i.e., below the asynchronous
module's priority of 300).

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Catalin Marinas