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 06/12] RISC-V: crypto: add accelerated AES-CBC/CTR/ECB/XTS
 implementations
From:   Jerry Shih <jerry.shih@sifive.com>
In-Reply-To: <CF7F714A-CAC1-41C4-A43A-DA1273111492@sifive.com>
Date:   Mon, 20 Nov 2023 10:36:19 +0800
Cc:     Paul Walmsley <paul.walmsley@sifive.com>, palmer@dabbelt.com,
        Albert Ou <aou@eecs.berkeley.edu>, herbert@gondor.apana.org.au,
        davem@davemloft.net, andy.chiu@sifive.com, greentime.hu@sifive.com,
        conor.dooley@microchip.com, guoren@kernel.org, bjorn@rivosinc.com,
        heiko@sntech.de, ardb@kernel.org, phoebe.chen@sifive.com,
        hongrong.hsu@sifive.com, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4290995-3983-41D8-991E-ABA2213656B1@sifive.com>
References: <20231025183644.8735-1-jerry.shih@sifive.com>
 <20231025183644.8735-7-jerry.shih@sifive.com>
 <20231109080549.GC1245@sol.localdomain>
 <CF7F714A-CAC1-41C4-A43A-DA1273111492@sifive.com>
To:     Eric Biggers <ebiggers@kernel.org>
Precedence: bulk

On Nov 10, 2023, at 12:06, Jerry Shih <jerry.shih@sifive.com> wrote:
> On Nov 9, 2023, at 16:05, Eric Biggers <ebiggers@kernel.org> wrote:
>> On Thu, Oct 26, 2023 at 02:36:38AM +0800, Jerry Shih wrote:
>>> +# prepare input data(v24), iv(v28), bit-reversed-iv(v16), =
bit-reversed-iv-multiplier(v20)
>>> +sub init_first_round {
>>> ....
>>> +    # Prepare GF(2^128) multiplier [1, x, x^2, x^3, ...] in v8.
>>> +    slli $T0, $LEN32, 2
>>> +    @{[vsetvli "zero", $T0, "e32", "m1", "ta", "ma"]}
>>> +    # v2: [`1`, `1`, `1`, `1`, ...]
>>> +    @{[vmv_v_i $V2, 1]}
>>> +    # v3: [`0`, `1`, `2`, `3`, ...]
>>> +    @{[vid_v $V3]}
>>> +    @{[vsetvli "zero", $T0, "e64", "m2", "ta", "ma"]}
>>> +    # v4: [`1`, 0, `1`, 0, `1`, 0, `1`, 0, ...]
>>> +    @{[vzext_vf2 $V4, $V2]}
>>> +    # v6: [`0`, 0, `1`, 0, `2`, 0, `3`, 0, ...]
>>> +    @{[vzext_vf2 $V6, $V3]}
>>> +    slli $T0, $LEN32, 1
>>> +    @{[vsetvli "zero", $T0, "e32", "m2", "ta", "ma"]}
>>> +    # v8: [1<<0=3D1, 0, 0, 0, 1<<1=3Dx, 0, 0, 0, 1<<2=3Dx^2, 0, 0, =
0, ...]
>>> +    @{[vwsll_vv $V8, $V4, $V6]}
>>=20
>> This code assumes that '1 << i' fits in 64 bits, for 0 <=3D i < vl.
>>=20
>> I think that works out to an implicit assumption that VLEN <=3D 2048. =
 I.e.,
>> AES-XTS encryption/decryption would produce the wrong result on =
RISC-V
>> implementations with VLEN > 2048.
>>=20
>> Perhaps it should be explicitly checked that VLEN <=3D 2048?
>>=20
>> - Eric
>=20
> Yes, we could just have the simple checking like:
>=20
>  riscv_vector_vlen() >=3D 128 || riscv_vector_vlen() <=3D2048
>=20
> We could also truncate the VL inside for VLEN>2048 case.
> Let me think more about these two approaches.=20
>=20
> -Jerry

I use the simplest solution. Setup the check for vlen:
	riscv_vector_vlen() >=3D 128 || riscv_vector_vlen() <=3D2048
It will have a situation that we will not enable accelerated aes-xts for =
`vlen>2048`.
I would like to make a `todo` task to fix that in the future.

-Jerry=