linux-kernel - Re: [RFC PATCH] crypto: riscv: scalar accelerated GHASH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALW65jY=LnVBYoKPOQnSKgGSA0brKzmo0vqoRDcqF_=jofLAng@mail.gmail.com>
Date: Thu, 17 Apr 2025 15:25:38 +0800
From: Qingfang Deng <dqfext@...il.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Eric Biggers <ebiggers@...nel.org>, Herbert Xu <herbert@...dor.apana.org.au>, 
	"David S. Miller" <davem@...emloft.net>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Alexandre Ghiti <alex@...ti.fr>, linux-crypto@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Christoph Müllner <christoph.muellner@...ll.eu>, 
	Heiko Stuebner <heiko.stuebner@...ll.eu>, Qingfang Deng <qingfang.deng@...lower.com.cn>
Subject: Re: [RFC PATCH] crypto: riscv: scalar accelerated GHASH

Hi Ard,

On Thu, Apr 17, 2025 at 2:58 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> (cc Eric)
>
> On Thu, 17 Apr 2025 at 08:49, Qingfang Deng <dqfext@...il.com> wrote:
> >
> > From: Qingfang Deng <qingfang.deng@...lower.com.cn>
> >
> > Add a scalar implementation of GHASH for RISC-V using the Zbc (carry-less
> > multiplication) and Zbb (bit-manipulation) extensions. This implementation
> > is adapted from OpenSSL but rewritten in plain C for clarity.
> >
> > Unlike the OpenSSL one that rely on bit-reflection of the data, this
> > version uses a pre-computed (reflected and multiplied) key, inspired by
> > the approach used in Intel's CLMUL driver, to avoid reflections during
> > runtime.
> >
> > Signed-off-by: Qingfang Deng <qingfang.deng@...lower.com.cn>
>
> What is the use case for this? AIUI, the scalar AES instructions were
> never implemented by anyone, so how do you expect this to be used in
> practice?

The use case _is_ AES-GCM, as you mentioned. Without this, computing
GHASH can take a considerable amount of CPU time (monitored by perf).

> ...
> > +static __always_inline __uint128_t get_unaligned_be128(const u8 *p)
> > +{
> > +       __uint128_t val;
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS means that get_unaligned_xxx()
> helpers are cheap. Casting a void* to an aligned type is still UB as
> per the C standard.

Technically an unaligned access is UB but this pattern is widely used
in networking code.

>
> So better to drop the #ifdef entirely, and just use the
> get_unaligned_be64() helpers for both cases.

Currently those helpers won't generate rev8 instructions, even if
HAVE_EFFICIENT_UNALIGNED_ACCESS and RISCV_ISA_ZBB is set, so I have to
implement my own version of this to reduce the number of instructions,
and to align with the original OpenSSL implementation.

>
> (same below)
>
> Also, do you need to test for int128 support? Or is that guaranteed
> for all compilers that are supported by the RISC-V port?

I believe int128 support is available for all 64-bit targets.