Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Wed, 17 Jun 2020 23:36:11 +0000
> From: Taylor R Campbell <[email protected]>
> 
> [bcc tech-crypto, tech-security; followups to tech-kern]
> 
> It's been well-known since 2005[1] that naive AES software, like we
> use today in the NetBSD kernel, is vulnerable to cache-timing attacks
> (CVE-2005-1797).  These attacks have gotten progressively better over
> time, and over a decade ago were even applied to Linux dm-crypt disk
> encryption[2].
> [...]
> The attached patch set provides a three-pronged approach to addressing
> the problem:

FYI, I committed this today.  The NetBSD kernel has no more vulnerable
AES software -- all architectures at least have BearSSL's bitsliced
32-bit aes_ct software to fall back to if there's no faster MD AES
implementation.

Aside from adding Adiantum to cgd(4) in order to provide better
software performance and security than AES-CBC or AES-XTS can, I also
added:

- AES-NI on amd64 for most high-end x86 <=10 years old
- bitsliced AES four blocks at a time with SSE2 on all x86
- permutation-based AES (vpaes) with SSSE3 on most x86 <=15 years old
- VIA ACE AES on VIA CPUs (not just via opencrypto as we had before)
- ARMv8.0-AES on aarch64 for all but the cheapest aarch64 CPUs
- permutation-based AES (vpaes) with ARM NEON on most armv7-a and
  aarch64, even cheap aarch64 like rpi

I left in the complicated legacy rijndael_* API -- implemented in
terms of the new aes_* API which takes advantage of any CPU support --
because it is still used in net80211.  Once the wifi branch is done,
or if the wifi branch is rebased on HEAD, we can delete it there too.

Let me know if there's any fallout, or if you're interested in
extending it to other CPUs or vector units!