summaryrefslogtreecommitdiffstats
path: root/arch/arm64/crypto/Kconfig
diff options
context:
space:
mode:
authorArd Biesheuvel2017-01-29 00:25:38 +0100
committerHerbert Xu2017-02-03 11:16:20 +0100
commit4edd7d015b95abcedde591a0c45965305d7cd524 (patch)
tree7b81ab35751743010bc72a9788f562fa0dc8e033 /arch/arm64/crypto/Kconfig
parentcrypto: arm64/aes - performance tweak (diff)
downloadkernel-qcow2-linux-4edd7d015b95abcedde591a0c45965305d7cd524.tar.gz
kernel-qcow2-linux-4edd7d015b95abcedde591a0c45965305d7cd524.tar.xz
kernel-qcow2-linux-4edd7d015b95abcedde591a0c45965305d7cd524.zip
crypto: arm64/aes-neon-blk - tweak performance for low end cores
The non-bitsliced AES implementation using the NEON is highly sensitive to micro-architectural details, and, as it turns out, the Cortex-A53 on the Raspberry Pi 3 is a core that can benefit from this code, given that its scalar AES performance is abysmal (32.9 cycles per byte). The new bitsliced AES code manages 19.8 cycles per byte on this core, but can only operate on 8 blocks at a time, which is not supported by all chaining modes. With a bit of tweaking, we can get the plain NEON code to run at 22.0 cycles per byte, making it useful for sequential modes like CBC encryption. (Like bitsliced NEON, the plain NEON implementation does not use any lookup tables, which makes it easy on the D-cache, and invulnerable to cache timing attacks) So tweak the plain NEON AES code to use tbl instructions rather than shl/sri pairs, and to avoid the need to reload permutation vectors or other constants from memory in every round. Also, improve the decryption performance by switching to 16x8 pmul instructions for the performing the multiplications in GF(2^8). To allow the ECB and CBC encrypt routines to be reused by the bitsliced NEON code in a subsequent patch, export them from the module. 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')
0 files changed, 0 insertions, 0 deletions