> From: Greg Troxel <[email protected]> > Date: Wed, 28 Oct 2026 07:57:20 -0400 > > Reading wikipedia, it seems that almost all x86 processors in the last > 12+ years have AES support. Even my (getting to be too slow to use) PC > Engines apu2 has it. > > Beyond x86, wikipedia says there is hardware support on sparc after > 2011. It says most aarch64, but a RPI4 seems to lack it.. RISC-V is > less clear. That leaves out (32-bit) armv7, and retro arches.
There are many CPU architectures that can, in principle, do faster AES without provoking cache-timing attacks. But in practice: 1. As nia noted, we only have software to take advantage of AES instructions on aarch64 and amd64. We don't have any for: - arm32 - cnmips - i386 - powerpc - sparc If you are interested in working on any of these (or just vectorized versions like altivec) because it's useful to you or just fun, I'd be happy to help you! But it's not there now. 2. Even on x86, there are still a lot of low-end CPUs like Intel Atom that don't have AES-NI, according to <https://www.intel.com/content/www/us/en/products/sku/246037/intel-atom-p69223-processor-8m-cache-2-20-ghz/specifications.html>. (This page doesn't say it _doesn't_ have AES-NI, but a corresponding page for another microarchitecture chosen arbitrarily does explicitly say AES-NI is supported: <https://www.intel.com/content/www/us/en/products/sku/195334/intel-xeon-e2278ge-processor-16m-cache-3-30-ghz/specifications.html>.) 3. As you noticed, some very widespread aarch64 CPUs lack AES instructions. Likewise sparc and powerpc -- probably most if not all sparc and powerpc that NetBSD runs on, for that matter. 4. mips has never had any standard AES instructions, as far as I can tell, not even in the last release R6 (of which I'm not sure any silicon was ever fabricated), according to a search of: https://web.archive.org/web/20190616150521/https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00087-2B-MIPS64BIS-AFP-6.06.pdf https://web.archive.org/web/20190616150534/https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00594-2B-microMIPS64-AFP-6.05.pdf 5. riscv instruction set extensions are, from what I recall, a huge mess with no standard way to detect them like x86 CPUID. So even if we had software to take advantage of the Zknd and Zkne extensions, and ran on hardware that supports them, there's a good chance we wouldn't reliably detect the fact. This is why Adiantum is a better default recommendation for cgd(4) if you have not specifically confirmed your hardware has CPU AES support that NetBSD will use. (You can confirm it by querying sysctl kern.crypto.aes.selected and seeing whether it is `ARMv8.0-AES', `Intel AES-NI', or `VIA ACE' -- or just measure the read and write throughput of cgd with Adiantum vs AES.)
