Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 09:30, Herbert Xu [off-list ref] wrote:

On Tue, Jul 18, 2017 at 08:57:28AM +0100, Ard Biesheuvel wrote:

quoted

So if you care about security and/or the cache/memory footprint more
than about speed, you can disable the table based implementations that
exist for i586, x86, ARM and arm64 (all of which have faster and time
invariant implementations based on SIMD or special instructions
anyway, so for 95% of the cases, it does not really matter).

The thing is that anybody who cares about speed won't be using
aes-generic anyway.  We have way too many AES implementations
as it is, and having two C implementations is really getting
silly.

So would it be possible for you to proceed with your work in
such a way that we end up with just aes-ti as the generic C
implementation?

Sure.

As for the table-based asm implementations yes they can stay and
work out some way of sharing that table at the source-code level.
At run-time the table can just go into the asm module directly
since you'd only have one on each platform, right?

Indeed. And ARM only uses 4 of those 16 tables anyway (and really only
needs two of them, so I will fix that as well)