> Date: Thu, 18 Jun 2020 17:17:56 +0000
> From: Taylor R Campbell <riastr...@netbsd.org>
>
> > Date: Thu, 18 Jun 2020 09:37:36 -0700
> > From: Brian Buhrow <buh...@nfbcal.org>
> >
> > 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.
