cipher/rijndael-riscv-zvkned.c's m4 batching code assumes m1 holds exactly one 16-byte AES block (i.e. VLEN == 128). On VLEN >= 256 the four-block m4 group is laid out differently and AES_CRYPT m4 vl=16 miscomputes blocks 1..3.
Replace the existing __riscv_vsetvl_e32m1(4) == 4 gate (which only checked "VLEN >= 128") with __riscv_vsetvlmax_e32m1() == 4 (== 4 if VLEN == 128). On any other VLEN the backend refuses setup and libgcrypt's dispatcher in cipher/rijndael.c falls through to USE_VP_RISCV (rijndael-vp-riscv.c), which is Zvbb-based and has no VLEN dependency. Issue found by Claude Opus using qemu on Tenstorrent Ascalon model (-cpu tt-ascalon). Tested-on: tt-ascalon (VLEN=256) under qemu 9.1.92 Tested-on: rva23s64 (VLEN=128) under qemu 9.1.92 Signed-off-by: Michael Neuling <[email protected]> --- cipher/rijndael-riscv-zvkned.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/cipher/rijndael-riscv-zvkned.c b/cipher/rijndael-riscv-zvkned.c index 434b9562be..d083c05703 100644 --- a/cipher/rijndael-riscv-zvkned.c +++ b/cipher/rijndael-riscv-zvkned.c @@ -142,7 +142,10 @@ int ASM_FUNC_ATTR_NOINLINE FUNC_ATTR_OPT_O2 _gcry_aes_riscv_zvkned_setup_acceleration(RIJNDAEL_context *ctx) { (void)ctx; - return (__riscv_vsetvl_e32m1(4) == 4); + /* The m4 batching code assumes m1 holds exactly one 16-byte + AES block (i.e. VLEN == 128). Refuse the backend on any other + VLEN. */ + return (__riscv_vsetvlmax_e32m1() == 4); } -- 2.43.0 _______________________________________________ Gcrypt-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
