arch/arm64: AES using the Armv8 Cryptography Extension

[royzah]

Summary

NuttX emits no AES instruction on any core. arm64 has no runtime feature dispatch, so a part that implements the Cryptography Extension still runs the table version in https://github.com/apache/nuttx/blob/master/crypto/rijndael.c, which indexes eight 256-entry tables with key-dependent values and therefore has cache-dependent timing.

This provides the crypto/aes.h block operations with AESE, AESD and the MixColumns pair, behind CONFIG_ARM64_CRYPTO_AES. ID_AA64ISAR0_EL1.AES is read at key setup, so a core without the extension gets a failed aes_setkey rather than an undefined instruction.

Two points for review:

• The key schedule stays in C apart from SubWord, which borrows AESE with a zero round key. That only yields the substituted word if ShiftRows has nothing to move, so the word is replicated across all four columns first.
• Decryption uses the equivalent inverse cipher: InvMixColumns is folded into the middle round keys at setup, so the block path is the same shape as encryption.

Impact

arm64, opt-in, off by default. New file, no existing behaviour changes. crypto/rijndael.c is untouched and remains what xform.c uses.

Testing

Verified against the FIPS-197 appendix C vectors for 128, 192 and 256 bits, both directions, executing the instructions under qemu-aarch64:

ok   AES-128        ok   AES-128 decrypt
ok   AES-192        ok   AES-192 decrypt
ok   AES-256        ok   AES-256 decrypt
all FIPS-197 vectors pass

tools/nxstyle clean.

Owed before ready: throughput against the table version on a real part, and a boot log. Both need hardware this branch does not have.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

should we implement as crypto driver?

[royzah]

Yes. And it found a bug: my file and crypto/aes.c define the same five functions, so both on will not link.

aes_cypher() avoids that, like stm32h7 and esp32, but then only /dev/crypto gets it, not xform.c. Prefer that?