From: Heiko Stuebner <heiko.stuebner@vrull.eu>

This was originally part of my vector crypto series, but was part
of a separate openssl merge request implementing GCM ghash as using
non-vector extensions.

As that pull-request
    https://github.com/openssl/openssl/pull/20078
got merged recently into openssl, we could also check if this could
go into the kernel as well and provide a base for further accelerated
cryptographic support.

Changes in v5:
- rebased on top of 6.4-based riscv/next
- code from openssl is now dual-licensed under Apache + BSD
  see https://github.com/openssl/openssl/pull/20649
- separate init functions instead of creating them with macros (Nathan)

Changes in v4:
- rebase on top of riscv/for-next
- split out the scalar crypto implementation from the vector series
- refresh code from openSSL to match exactly
- Remove RFC label, as Zbc and Zbkb are ratified and
  the cryptographic code was merged into openSSL

changes in v3:
- rebase on top of 6.3-rc2
- rebase on top of vector-v14 patchset
- add the missing Co-developed-by mentions to showcase
  the people that did the actual openSSL crypto code

changes in v2:
- rebased on 6.2 + zbb series, so don't include already
  applied changes anymore
- refresh code picked from openssl as that side matures
- more algorithms (SHA512, AES, SM3, SM4)

Heiko Stuebner (4):
  RISC-V: add Zbc extension detection
  RISC-V: add Zbkb extension detection
  RISC-V: hook new crypto subdir into build-system
  RISC-V: crypto: add accelerated GCM GHASH implementation

 arch/riscv/Kbuild                      |   1 +
 arch/riscv/Kconfig                     |  22 ++
 arch/riscv/crypto/Kconfig              |  18 ++
 arch/riscv/crypto/Makefile             |  18 ++
 arch/riscv/crypto/ghash-riscv64-glue.c | 296 +++++++++++++++++
 arch/riscv/crypto/ghash-riscv64-zbc.pl | 427 +++++++++++++++++++++++++
 arch/riscv/crypto/riscv.pm             | 258 +++++++++++++++
 arch/riscv/include/asm/hwcap.h         |   2 +
 arch/riscv/kernel/cpu.c                |   2 +
 arch/riscv/kernel/cpufeature.c         |   2 +
 crypto/Kconfig                         |   3 +
 11 files changed, 1049 insertions(+)
 create mode 100644 arch/riscv/crypto/Kconfig
 create mode 100644 arch/riscv/crypto/Makefile
 create mode 100644 arch/riscv/crypto/ghash-riscv64-glue.c
 create mode 100644 arch/riscv/crypto/ghash-riscv64-zbc.pl
 create mode 100644 arch/riscv/crypto/riscv.pm

-- 
2.39.0

Hi Heiko,

On Mon, Jun 12, 2023 at 11:04:38PM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@vrull.eu>
> 
> This was originally part of my vector crypto series, but was part
> of a separate openssl merge request implementing GCM ghash as using
> non-vector extensions.
> 
> As that pull-request
>     https://github.com/openssl/openssl/pull/20078
> got merged recently into openssl, we could also check if this could
> go into the kernel as well and provide a base for further accelerated
> cryptographic support.

I'm still a bit skeptical of the usefulness of a standalone "ghash"
implementation, when in practice it will only be used as part of "gcm(aes)".
Directly implementing "gcm(aes)" (instead of relying on crypto/gcm.c to compose
"ghash" and "ctr(aes)") also allows some performance optimizations.

I asked about this on v4
(https://lore.kernel.org/linux-crypto/ZCSG71bRuTzVutdm@gmail.com/),
but I didn't receive a response.

Any thoughts on this?

- Eric

Hi Eric,

Am Dienstag, 13. Juni 2023, 05:02:16 CEST schrieb Eric Biggers:
> Hi Heiko,
> 
> On Mon, Jun 12, 2023 at 11:04:38PM +0200, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner@vrull.eu>
> > 
> > This was originally part of my vector crypto series, but was part
> > of a separate openssl merge request implementing GCM ghash as using
> > non-vector extensions.
> > 
> > As that pull-request
> >     https://github.com/openssl/openssl/pull/20078
> > got merged recently into openssl, we could also check if this could
> > go into the kernel as well and provide a base for further accelerated
> > cryptographic support.
> 
> I'm still a bit skeptical of the usefulness of a standalone "ghash"
> implementation, when in practice it will only be used as part of "gcm(aes)".
> Directly implementing "gcm(aes)" (instead of relying on crypto/gcm.c to compose
> "ghash" and "ctr(aes)") also allows some performance optimizations.
> 
> I asked about this on v4
> (https://lore.kernel.org/linux-crypto/ZCSG71bRuTzVutdm@gmail.com/),
> but I didn't receive a response.
> 
> Any thoughts on this?

somehow I always seem to overlook this when adapting the series :-(

I guess for me the main gcm was always a stepping stone to get
started and extend later. This is my first rodeo with crypto stuff
in the kernel, so this looks like a manageable chunk and as can be
seen by the discussion we had about licensing brings enough topics
on its own :-) .


Heiko