Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: [PATCH v4 00/12] RISC-V: support some cryptography accelerations
From:   He-Jie Shih <bignose1007@gmail.com>
In-Reply-To: <20231006194741.GA68531@google.com>
Date:   Sat, 7 Oct 2023 05:01:45 +0800
Cc:     Charlie Jenkins <charlie@rivosinc.com>,
        Heiko Stuebner <heiko@sntech.de>, palmer@dabbelt.com,
        paul.walmsley@sifive.com, aou@eecs.berkeley.edu,
        herbert@gondor.apana.org.au, davem@davemloft.net,
        conor.dooley@microchip.com, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        christoph.muellner@vrull.eu,
        Heiko Stuebner <heiko.stuebner@vrull.eu>
Reply-To: 20231006194741.GA68531@google.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BC51820-61BC-422C-A2F7-B68CE679972C@gmail.com>
References: <20230711153743.1970625-1-heiko@sntech.de>
 <20230914001144.GA924@sol.localdomain> <ZQJdnCwf99Glggin@ghost>
 <3A0F6A71-C521-44A5-A56C-076AF3E13897@gmail.com>
 <DD3113B1-AB9F-4D6D-BD6E-8F75A83DA45D@sifive.com>
 <20231006194741.GA68531@google.com>
To:     Eric Biggers <ebiggers@kernel.org>
Precedence: bulk

On Oct 7, 2023, at 03:47, Eric Biggers <ebiggers@kernel.org> wrote:
> On Fri, Sep 15, 2023 at 11:21:28AM +0800, Jerry Shih wrote:
>> On Sep 15, 2023, at 09:48, He-Jie Shih <bignose1007@gmail.com> wrote:
>> The OpenSSL PR is at [1].
>> And we are from SiFive.
>>=20
>> -Jerry
>>=20
>> [1]
>> https://github.com/openssl/openssl/pull/21923
>=20
> Hi Jerry, I'm wondering if you have an update on this?  Do you need =
any help?

We have specialized aes-cbc/ecb/ctr patch locally and pass the `testmgr` =
test
cases. But the test patterns in `testmgr` are quite simple, I think it =
doesn't test the
corner case(e.g. aes-xts with tail element).

For aes-xts, I'm trying to update the implementation from OpenSSL. The =
design
philosophy is different between OpenSSL and linux. In linux crypto, the =
data will
be split into `scatterlist`. I need to preserve the aes-xts's iv for =
each scatterlist
entry call. And I'm thinking about how to handle the tail data in a =
simple way.
By the way, the `xts(aes)` implementation for arm and x86 are using
`cra_blocksize=3D AES_BLOCK_SIZE`. I don't know why we need to handle =
the tail
element. I think we will hit `EINVAL` error in `skcipher_walk_next()` if =
the data size
it not be a multiple of block size.

Overall, we will have
1) aes cipher
2) aes with cbc/ecb/ctr/xts mode
3) sha256/512 for `vlen>=3D128` platform
4) sm3 for `vlen>=3D128` platform
5) sm4
6) ghash
7) `chacha20` stream cipher

The vector crypto pr in OpenSSL is under reviewing, we are still =
updating the
perl file into linux.

The most complicated `gcm(aes)` mode will be in our next plan.

> I'm also wondering about riscv.pm and the choice of generating the =
crypto
> instructions from .words instead of using the assembler.  It makes it
> significantly harder to review the code, IMO.  Can we depend on =
assembler
> support for these instructions, or is that just not ready yet?

I have asked the same question before[1]. The reason is that Openssl =
could use
very old compiler for compiling. Thus, the assembler might not know the =
standard
rvv 1.0[2] and other vector crypto[3] instructions. That's why we use =
opcode for all
vector instructions. IMO, I would prefer to use opcode for `vector =
crypto` only. The
gcc-12 and clang-14 are already supporting rvv 1.0. Actually, I just =
read the `perl`
file instead of the actually generated opcode for OpenSSL pr reviewing. =
And it's
not hard to read the perl code.


Thanks,
- Jerry

[1]
https://github.com/openssl/openssl/pull/20149#discussion_r1244655440
[2]
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc
[3
=
https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-sp=
ec-vector.adoc]=