> Date: Thu, 18 Jun 2020 07:19:43 +0200 > From: Martin Husemann <mar...@duskware.de> > > 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.
