From: Ard Biesheuvel <ardb@xxxxxxxxxx>
The AES-CCM driver was written 10+ years ago, based on the very first
kernel mode NEON API for arm64, which eagerly preserved/restored the
NEON registers on each call to kernel_neon_begin() resp.
kernel_neon_end().
For this reason, the asm helpers were constructed in a way that used
only 6 NEON registers, as the kernel mode NEON API at the time
implemented an optimization where kernel_neon_begin() took an int
denoting the number of NEON registers to preserve/restore. Given that no
actual hardware existed at the time (except perhaps for APM Xgene1 which
did not implement the crypto instructions), all of this was based on
premature assumptions.
These days, the NEON API is a bit more sophisticated, and does not
bother to preserve/restore anything unless it is needed (e.g., when
context switching or returning to user space). It also no longer
disables preemption. Finally, we've developed some code patterns in the
mean time to deal with tail blocks more cleanly and efficiently.
So let's bring the CCM driver up to date with all of this.
Changes since v1:
- keep primary en/decryption paths separate
- fix rebase error in v1
Ard Biesheuvel (8):
crypto: arm64/aes-ccm - Revert "Rewrite skcipher walker loop"
crypto: arm64/aes-ccm - Keep NEON enabled during skcipher walk
crypto: arm64/aes-ccm - Pass short inputs via stack buffer
crypto: arm64/aes-ccm - Replace bytewise tail handling with NEON
permute
crypto: arm64/aes-ccm - Reuse existing MAC update for AAD input
crypto: arm64/aes-ccm - Cache round keys and unroll AES loops
crypto: arm64/aes-ccm - Merge encrypt and decrypt tail handling
crypto: arm64/aes-ccm - Merge finalization into en/decrypt asm helpers
arch/arm64/crypto/Kconfig | 1 +
arch/arm64/crypto/aes-ce-ccm-core.S | 265 +++++++-------------
arch/arm64/crypto/aes-ce-ccm-glue.c | 154 ++++++++----
arch/arm64/crypto/aes-glue.c | 1 +
4 files changed, 200 insertions(+), 221 deletions(-)
--
2.43.0.381.gb435a96ce8-goog
