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

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

> Date: Thu, 18 Jun 2020 17:17:56 +0000
> From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
> 
> > Date: Thu, 18 Jun 2020 09:37:36 -0700
> > From: Brian Buhrow <buhrow%nfbcal.org@localhost>
> > 
> > 	hello.  I have what may be a silly question.  Does this change mean
> > that I386 users won't have AES capabilities in the kernel at all going
> > forward?  (I gather that's true for architectures like Sparc, but I'm
> > assuming the AES code we did have didn't run very well on Sparc anyway.)
> > However, it seems we still have a number of I386 users and I'm wondering
> > where this leaves them?
> 
> No functionality is lost: there was, and there remains, a software
> implementation of AES that can be used in cgd, ipsec, /dev/crypto with
> swcrypto, &c., even if the CPU doesn't have AES instructions that we
> can take advantage of.

I should clarify that when I said

   2. Add support for CPU AES instructions on Intel, AMD, VIA, and
      aarch64 CPUs to implement the kernel's synchronous AES API,

and then noted that as future work,

     With a little more effort we could:
     - adapt the x86 AES-NI logic to 32-bit mode

what I meant is that in _adding_ x86 AES-NI logic I only implemented
it in 64-bit mode.  The patch set doesn't _take away_ AES-NI logic in
32-bit mode because we never had that to begin with -- the only AES
logic we've _ever_ had in the kernel is the vulnerable AES reference
implementation.

I don't expect a lot of users will run x86 CPUs with AES-NI in 32-bit
mode, so I didn't think it would be worth the effort just yet, but if
you are in this situation and it would benefit you, I'm happy to look
into it.