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

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

> Date: Thu, 18 Jun 2020 07:19:43 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> One minor nit: with the performance impact that high, and there being
> setups where runtime side channel attacks are totally not an issue,
> maybe we should leave the old code in place for now, #ifdef'd as
> default-off options to provide time for a full reconstruction (or untill
> the machine gets update to "the last decade" cpu)?

Having leaky AES code around is asking for trouble -- and would
require additional complexity to implement and maintain (e.g., is it
always unhooked from the build, or do we hook it in just enough to run
tests?), which would add further burden on an audit to verify that
it's _not_ being used in a real application.

The goals here are to make that burden completely go away by making
the answer unconditionally no, there's essentially no danger that AES
in the kernel is leaky; and to provide alternatives with performance
ranging from `not worse' to `much better' to avoid the conflict that
AES invites between performance and security.

If you have a specific system where there's a real negative
performance impact that matters to you, I would be happy to talk over
the details and see how we can address it better.