crypto: riscv/aes - Implement scalar Zkn version for RV32

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 <[email protected]>

Cc Palmer Dabbelt <[email protected]>

Cc Albert Ou <[email protected]>

Cc Christoph Müllner <[email protected]>

Cc Heiko Stuebner <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 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(+)

Quoted 25 lines · Ard Biesheuvel

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 <[email protected]>

Cc Palmer Dabbelt <[email protected]>

Cc Albert Ou <[email protected]>

Cc Christoph Müllner <[email protected]>

Cc Heiko Stuebner <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

Quoted 6 lines

---
 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?

Quoted 1 line · Herbert Xu

Quoted 5 lines

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

I don't really know much about the crypto stuff, but looks like there's still a "struct crypto_cipher" in my trees. Am I still supposed to be waiting on something?

Quoted 19 lines · Palmer Dabbelt

Quoted 17 lines · Ard Biesheuvel

Quoted 3 lines · Ard Biesheuvel

Quoted 1 line · Herbert Xu

...

Quoted 9 lines

Quoted 5 lines

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

Is this still happening?

Quoted 3 lines

I don't really know much about the crypto stuff, but looks like there's still a "struct crypto_cipher" in my trees. Am I still supposed to be waiting on something?

Regardless of crypto_cipher structs, this needs whatever series that actually implements Zkn detection from DT/ACPI to be merged first, as otherwise the definitions that iscv_isa_extension_available() depends on don't exist.