diff options
| author | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2017-01-28 23:25:39 +0000 |
|---|---|---|
| committer | Herbert Xu <herbert@gondor.apana.org.au> | 2017-02-03 18:16:20 +0800 |
| commit | 12fcd92305880504c9827c99ea128fecf1c99f0d (patch) | |
| tree | 49a2ccb419da7504484adba42996282c373d950d /arch/arm64/crypto/Kconfig | |
| parent | 4edd7d015b95abcedde591a0c45965305d7cd524 (diff) | |
| download | talos-obmc-linux-12fcd92305880504c9827c99ea128fecf1c99f0d.tar.gz talos-obmc-linux-12fcd92305880504c9827c99ea128fecf1c99f0d.zip | |
crypto: arm64/aes - replace scalar fallback with plain NEON fallback
The new bitsliced NEON implementation of AES uses a fallback in two
places: CBC encryption (which is strictly sequential, whereas this
driver can only operate efficiently on 8 blocks at a time), and the
XTS tweak generation, which involves encrypting a single AES block
with a different key schedule.
The plain (i.e., non-bitsliced) NEON code is more suitable as a fallback,
given that it is faster than scalar on low end cores (which is what
the NEON implementations target, since high end cores have dedicated
instructions for AES), and shows similar behavior in terms of D-cache
footprint and sensitivity to cache timing attacks. So switch the fallback
handling to the plain NEON driver.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'arch/arm64/crypto/Kconfig')
| -rw-r--r-- | arch/arm64/crypto/Kconfig | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig index 5de75c3dcbd4..bed7feddfeed 100644 --- a/arch/arm64/crypto/Kconfig +++ b/arch/arm64/crypto/Kconfig @@ -86,7 +86,7 @@ config CRYPTO_AES_ARM64_BS tristate "AES in ECB/CBC/CTR/XTS modes using bit-sliced NEON algorithm" depends on KERNEL_MODE_NEON select CRYPTO_BLKCIPHER - select CRYPTO_AES_ARM64 + select CRYPTO_AES_ARM64_NEON_BLK select CRYPTO_SIMD endif |
