Skip to content

crypto: Clean up arm64 AES-CCM code

Ard Biesheuvel linux-crypto 2 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest8 patches 1 replyIn review
  2. v18 patches 1 replySuperseded

Changes in v2 from the cover letter

- keep primary en/decryption paths separate
- fix rebase error in v1

Patches in v2 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/8crypto: arm64/aes-ccm - Revert "Rewrite skcipher walker loop"arch/arm64/crypto/aes-ce-ccm-glue.c+31 -260 replies
2/8crypto: arm64/aes-ccm - Keep NEON enabled during skcipher walkarch/arm64/crypto/aes-ce-ccm-glue.c+10 -120 replies
3/8crypto: arm64/aes-ccm - Pass short inputs via stack bufferarch/arm64/crypto/aes-ce-ccm-glue.c+40 -170 replies
4/8crypto: arm64/aes-ccm - Replace bytewise tail handling with NEON permutearch/arm64/crypto/aes-ce-ccm-core.S+38 -210 replies
5/8crypto: arm64/aes-ccm - Reuse existing MAC update for AAD inputarch/arm64/crypto/Kconfig arch/arm64/crypto/aes-ce-ccm-core.S arch/arm64/crypto/aes-ce-ccm-glue.c +1 more+43 -790 replies
6/8crypto: arm64/aes-ccm - Cache round keys and unroll AES loopsarch/arm64/crypto/aes-ce-ccm-core.S+38 -570 replies
7/8crypto: arm64/aes-ccm - Merge encrypt and decrypt tail handlingarch/arm64/crypto/aes-ce-ccm-core.S+13 -130 replies
8/8crypto: arm64/aes-ccm - Merge finalization into en/decrypt asm helpersarch/arm64/crypto/aes-ce-ccm-core.S arch/arm64/crypto/aes-ce-ccm-glue.c+29 -380 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [PATCH v2 0/8] crypto: Clean up arm64 AES-CCM code

From: Ard Biesheuvel <[email protected]>

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(-)
Signature · 1 line
2.43.0.381.gb435a96ce8-goog