mbox series

[v4,0/4] Implement GCM ghash using Zbc and Zbkb extensions

Message ID 20230329140642.2186644-1-heiko.stuebner@vrull.eu (mailing list archive)
Headers show
Series Implement GCM ghash using Zbc and Zbkb extensions | expand

Message

Heiko Stuebner March 29, 2023, 2:06 p.m. UTC
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 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 | 258 ++++++++++++++++
 arch/riscv/crypto/ghash-riscv64-zbc.pl | 400 +++++++++++++++++++++++++
 arch/riscv/crypto/riscv.pm             | 231 ++++++++++++++
 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, 957 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

Comments

Eric Biggers March 29, 2023, 6:43 p.m. UTC | #1
Hi Heiko,

On Wed, Mar 29, 2023 at 04:06:38PM +0200, Heiko Stuebner wrote:
>
> [PATCH v4 0/4] Implement GCM ghash using Zbc and Zbkb extensions

Has there been consideration of implementing AES-GCM instead of GHASH by itself?
This is what arm64 does, for example.  There is not currently any use case for
GHASH outside of AES-GCM, and it's more efficient to implement the full AES-GCM.

- Eric
Eric Biggers April 26, 2023, 10:55 p.m. UTC | #2
Hi Heiko,

On Wed, Mar 29, 2023 at 04:06: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.

One more question.  It seems that this patchset uses the RISC-V scalar crypto
extensions.  I've been hearing rumors that the RISC-V scalar crypto extensions
have been superseded by the vector crypto extensions.  Is that accurate?  I
wonder if it's worth putting effort into implementations that use the scalar
crypto extensions when they might already be obsolete.

- Eric
Heiko Stuebner April 26, 2023, 11:20 p.m. UTC | #3
Hi Eric,

Am Donnerstag, 27. April 2023, 00:55:50 CEST schrieb Eric Biggers:
> On Wed, Mar 29, 2023 at 04:06: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.
> 
> One more question.  It seems that this patchset uses the RISC-V scalar crypto
> extensions.  I've been hearing rumors that the RISC-V scalar crypto extensions
> have been superseded by the vector crypto extensions.  Is that accurate?  I
> wonder if it's worth putting effort into implementations that use the scalar
> crypto extensions when they might already be obsolete.

Yes there are the vector crypto extensions - still deep in the
ratification process.

And of course the RISC-V speciality, all extensions are separate
entities that core manufacturers can select at will.

And I guess the whole vector extension + vector-crypto extensions
might require more investment for manufacturers, where the variants
introduced here also "just" work with bitmanip instructions (Zbb + Zbc
extensions).


But for me, this small bit of scalar crypto is also sort of a stepping
stone :-). Previous versions [0] already included patches using the
vector crypto extensions too, I just split that into a separate thing,
as _this_ series actually uses ratified extensions :-)


Heiko



[0] https://lore.kernel.org/lkml/20230313191302.580787-12-heiko.stuebner@vrull.eu/T/
Eric Biggers April 26, 2023, 11:23 p.m. UTC | #4
On Thu, Apr 27, 2023 at 01:20:31AM +0200, Heiko Stübner wrote:
> But for me, this small bit of scalar crypto is also sort of a stepping
> stone :-). Previous versions [0] already included patches using the
> vector crypto extensions too, I just split that into a separate thing,
> as _this_ series actually uses ratified extensions :-)
> 
> 
> Heiko
> 
> 
> 
> [0] https://lore.kernel.org/lkml/20230313191302.580787-12-heiko.stuebner@vrull.eu/T/

That patchset wasn't sent to linux-crypto.  Can you make sure to include
linux-crypto@vger.kernel.org on any subsequent patchsets?  Thanks!

- Eric
Heiko Stuebner April 26, 2023, 11:28 p.m. UTC | #5
Hi,

Am Donnerstag, 27. April 2023, 01:23:31 CEST schrieb Eric Biggers:
> On Thu, Apr 27, 2023 at 01:20:31AM +0200, Heiko Stübner wrote:
> > But for me, this small bit of scalar crypto is also sort of a stepping
> > stone :-). Previous versions [0] already included patches using the
> > vector crypto extensions too, I just split that into a separate thing,
> > as _this_ series actually uses ratified extensions :-)
> > 
> > 
> > Heiko
> > 
> > 
> > 
> > [0] https://lore.kernel.org/lkml/20230313191302.580787-12-heiko.stuebner@vrull.eu/T/
> 
> That patchset wasn't sent to linux-crypto.  Can you make sure to include
> linux-crypto@vger.kernel.org on any subsequent patchsets?  Thanks!

yeah, that was a fault on my part, which I managed to rectify with v4 here
[haven't had time to send the vector part as separate v4 yet]

Will include linux-crypto in further submissions.


Heiko