Re: The official disk encryption guide seems a bit lacking (detailed list of concrete improvement suggestions!)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> From: Greg Troxel <gdt%lexort.com@localhost>
> 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.)