On Fri, 4 Aug 2023 at 10:21, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 26, 2023 at 07:29:58PM +0200, Ard Biesheuvel wrote: > > The generic AES implementation we rely on if no architecture specific > > one is available relies on lookup tables that are relatively large with > > respect to the typical L1 D-cache size, which not only affects > > performance, it may also result in timing variances that correlate with > > the encryption keys. > > > > So we tend to avoid the generic code if we can, usually by using a > > driver that makes use of special AES instructions which supplant most of > > the logic of the table based implementation the AES algorithm. > > > > The Zkn RISC-V extension provides another interesting take on this: it > > defines instructions operating on scalar registers that implement the > > table lookups without relying on tables in memory. Those tables carry > > 32-bit quantities, making them a natural fit for a 32-bit architecture. > > And given the use of scalars, we don't have to rely in in-kernel SIMD, > > which is a bonus. > > > > So let's use the instructions to implement the core AES cipher for RV32. > > > > Cc: Paul Walmsley <paul.walmsley@xxxxxxxxxx> > > Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx> > > Cc: Albert Ou <aou@xxxxxxxxxxxxxxxxx> > > Cc: Christoph Müllner <christoph.muellner@xxxxxxxx> > > Cc: Heiko Stuebner <heiko.stuebner@xxxxxxxx> > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > --- > > arch/riscv/crypto/Kconfig | 12 ++ > > arch/riscv/crypto/Makefile | 3 + > > arch/riscv/crypto/aes-riscv32-glue.c | 75 ++++++++++++ > > arch/riscv/crypto/aes-riscv32-zkned.S | 119 ++++++++++++++++++++ > > 4 files changed, 209 insertions(+) > > Hi Ard: > > Any chance you could postpone this til after I've finished removing > crypto_cipher? > That's fine with me. Do you have an ETA on that? Need any help? I have implemented the scalar 64-bit counterpart as well in the mean time
