I was auditing the RVV and PPC64le native backends for anything the HOL-Light/CBMC proofs don't already cover (those are AArch64/x86_64-only). Noticed ct-tests.yml's matrix only runs on ubuntu-latest and ubuntu-24.04-arm there's no riscv64 or ppc64le entry, so the valgrind-based CT checks never touch these two, even though both are shipped as default production backends and both already get full functional/ACVP/Wycheproof coverage in CI (RVV via QEMU across the VLEN matrix, PPC64le on real POWER10 hardware). The runners and cross-execution setup already exist, they're just never pointed at a valgrind build, so CT correctness on these two currently rests on code-comment reasoning alone, with nothing dynamically catching a future secret-dependent branch the way KyberSlash originally got caught
on x86.
To be clear, this isn't a bug report. I actually tested RVV directly rather than just flagging the gap: differential-fuzzed keygen/encaps/decaps (including the implicit-rejection path) against the C reference across 500 vectors + edge cases at all four VLEN configs, then unit-tested the rejection-sampling boundary (3327-3331 around q=3329) across every lane position. All clean, byte-identical to reference throughout. That just confirms functional correctness though, which is a separate question from timing the CI gap on that front is still real. Didn't get a PPC64le cross-toolchain running to fuzz it the same way, but manually read the backend and it's the same shape as RVV, one fixed-iteration branch, no data-dependent indexing. Fix looks mechanical extend ct-tests.yml with riscv64/ppc64le entries reusing the existing QEMU/hardware runners, pointed at a valgrind build for those targets. Happy to help if useful.
I was auditing the RVV and PPC64le native backends for anything the HOL-Light/CBMC proofs don't already cover (those are AArch64/x86_64-only). Noticed ct-tests.yml's matrix only runs on ubuntu-latest and ubuntu-24.04-arm there's no riscv64 or ppc64le entry, so the valgrind-based CT checks never touch these two, even though both are shipped as default production backends and both already get full functional/ACVP/Wycheproof coverage in CI (RVV via QEMU across the VLEN matrix, PPC64le on real POWER10 hardware). The runners and cross-execution setup already exist, they're just never pointed at a valgrind build, so CT correctness on these two currently rests on code-comment reasoning alone, with nothing dynamically catching a future secret-dependent branch the way KyberSlash originally got caught
on x86.
To be clear, this isn't a bug report. I actually tested RVV directly rather than just flagging the gap: differential-fuzzed keygen/encaps/decaps (including the implicit-rejection path) against the C reference across 500 vectors + edge cases at all four VLEN configs, then unit-tested the rejection-sampling boundary (3327-3331 around q=3329) across every lane position. All clean, byte-identical to reference throughout. That just confirms functional correctness though, which is a separate question from timing the CI gap on that front is still real. Didn't get a PPC64le cross-toolchain running to fuzz it the same way, but manually read the backend and it's the same shape as RVV, one fixed-iteration branch, no data-dependent indexing. Fix looks mechanical extend ct-tests.yml with riscv64/ppc64le entries reusing the existing QEMU/hardware runners, pointed at a valgrind build for those targets. Happy to help if useful.