Review requested:

• @nodejs/security-wg

Have just spent a lot of today trying to unbreak my cross-compile environment but it's now working again. Will do some tests with this (natively and with the cross-compile) and see how it goes but this will be great if we can enable the assembly stuff now.

I encountered a strange OpenSSL compilation problem where it appears that the build system incorrectly fall-backs to x86_64 asm for a native riscv64 build: https://github.com/riscv-forks/node-riscv/actions/runs/24225505014/job/70735319923

I will give this PR a try in my new experimental CI system for riscv64: riscv-forks/node-riscv#1

I encountered a strange OpenSSL compilation problem where it appears that the build system incorrectly fall-backs to x86_64 asm for a native riscv64 build: https://github.com/riscv-forks/node-riscv/actions/runs/24225505014/job/70735319923

I will give this PR a try in my new experimental CI system for riscv64: riscv-forks/node-riscv#1

FYI I initially hit that as well when I hadn't included the --dest-cpu=riscv64 in the configure command when cross compiling (I typically run with CC and CXX set to clang with the appropriate --target and -march flags)

I encountered a strange OpenSSL compilation problem where it appears that the build system incorrectly fall-backs to x86_64 asm for a native riscv64 build: https://github.com/riscv-forks/node-riscv/actions/runs/24225505014/job/70735319923
I will give this PR a try in my new experimental CI system for riscv64: riscv-forks/node-riscv#1

FYI I initially hit that as well when I hadn't included the --dest-cpu=riscv64 in the configure command when cross compiling (I typically run with CC and CXX set to clang with the appropriate --target and -march flags)

Yeah, that might be expected in a cross-compilation setup. But I find it surprising because I am compiling natively on riscv64.

note: #62629 just landed with OpenSSL update to 3.5.6

Yeah, that might be expected in a cross-compilation setup. But I find it surprising because I am compiling natively on riscv64.

Interesting - my native build (clang21 with -march=rv64gc) seemed to go ok from this branch.

note: #62629 just landed with OpenSSL update to 3.5.6

Rebased on top of main and regenerated the riscv64 configs for 3.5.6.

@kxxt Done, added linux64-riscv64 to unofficial.gni. Thanks for the heads up.

Do we also need to update the following files?

@kxxt Yes, they did need updating. Added __riscv && __riscv_xlen == 64 to both templates, then regenerated the headers with make gen-openssl.

Hmmm I've built with this and if I've tested correctly it doesn't seem to show an improvement on the https tests (run without autocannon). I'd have hoped it would improve that a bit (as it does on x64). I might also try and compare with a version using the system openssl on my boards to see if that shows any difference but do you have any tests where the results are noticeable?

@sxa The asm codepaths for riscv64 in OpenSSL 3.5 are mostly scalar optimizations and AES/SHA intrinsics. The gains are probably more modest than x86 where you get AVX/AES-NI. If you're seeing no difference on HTTPS benchmarks specifically, it might be worth checking openssl speed aes-256-gcm sha256 with and without the asm build to isolate whether the crypto layer itself is faster, separate from the HTTP overhead.

@sxa The asm codepaths for riscv64 in OpenSSL 3.5 are mostly scalar optimizations and AES/SHA intrinsics. The gains are probably more modest than x86 where you get AVX/AES-NI. If you're seeing no difference on HTTPS benchmarks specifically, it might be worth checking openssl speed aes-256-gcm sha256 with and without the asm build to isolate whether the crypto layer itself is faster, separate from the HTTP overhead.

Trying with openssl speed aes-256-cbc sha256 (aes-256-gcm doesn't exist for speed) shows that sha256 doesn't show any improvement but I get about 16% improvement for aes-256-cbc when asm is enabled.

@sxa Thanks for running this. I dug a little bit more into what OpenSSL 3.5.6 actually ships, and what the hardware requirements are.

3.5.6 has no scalar SHA asm for RISC-V at all. The only file is sha256-riscv64-zvkb-zvknha_or_zvknhb.pl, gated on V+Zvkb+(Zvknha|Zvknhb)+VLEN≥128. Without those, sha_riscv.c falls through to C and this PR does nothing for SHA. Julian Zhu's Zbb-scalar variant (openssl/openssl#27381) is master/3.6 only.

Same on the asymmetric side: no BN-mont, no ECDSA-P256 in 3.5.6. BN-mont (openssl/openssl#28012) and SM2 (openssl/openssl#25918) are both 3.6. So the TLS handshake is unaffected by this PR regardless of hardware.

What's actually live on rv64gc is the generic 4-table AES asm (your 16% on aes-256-cbc), plus the V+Zbb ChaCha20 path if your hardware exposes it. The Zvkned AES, fused AES-GCM, and vector SHA paths all need the vector crypto extensions, which I don't think any shipping silicon has.

So for TLS 1.3 on rv64gc with this PR: the bulk cipher gets the AES-CBC boost on its AES portion, GHASH stays in C (no Zbc on rv64gc), SHA stays in C, handshake stays in C. A full HTTPS run on this hardware is dominated by paths the PR can't reach in 3.5.6.

The next OpenSSL bump should change that. BN-mont alone usually moves RSA handshake numbers by 5–10% on similar work for other arches, and the Zbb scalar SHA-256 lands at the same time.

@sxa Thanks for running this. I dug a little bit more into what OpenSSL 3.5.6 actually ships, and what the hardware requirements are.

Thanks that makes sense - the board I was primarily testing on (SpacemiT-K1) has the V extension with a suitable length but not the crypto vector bits. I guess we'll see if we get boost with the next openssl bump.

I did try a quick test by building a standalone openssl 3.5 vs 3.6 and it only seemed to show a 2% boost for openssl speed sha256 on my system, although the same under qemu (which presumably defaulted to having all the extensions) gave around a a 75% boost for sha256 between 3.5 and 3.6.

Unfortunately I'm not an expert in the area of openssl updates in Node so I'll tag @nodejs/crypto on this for a second opinion ...
While I don't expect it to be anything critical I am curious/nervous that we seemingly have some updates to AIX/Windows files. and I'd like a second opinion from someone more familiar with the update process before we approve this.

It's also a bit of a shame that lots of files are modified with a new date in the file so we have a lot of changes but that is likely perfectly normal so I'm less concerned about it.

Rebased onto latest main, which bumped OpenSSL to 3.5.7 after this branch was cut. I regenerated the linux64-riscv64 asm config against 3.5.7.

CI: https://ci.nodejs.org/job/node-test-pull-request/74705/

CI: https://ci.nodejs.org/job/node-test-pull-request/74717/

CI: https://ci.nodejs.org/job/node-test-pull-request/74718/

Landed in d6cd5c1