On 18 July 2017 at 09:30, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Tue, Jul 18, 2017 at 08:57:28AM +0100, Ard Biesheuvel wrote: >> >> 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)
