From: Daniel Golle <daniel@makrotopia.org>
Subject: [PATCH] JavaScriptCore: disable useWasmFastMemory on RISCV64

Base RISC-V doesn't require stores that fault to be atomic w.r.t. the
fault: hardware may commit some in-bound bytes of a 2/4/8-byte store
before raising the page-fault exception when the access straddles a
page boundary into PROT_NONE memory. SiFive U74 (StarFive JH7110)
does this.

JSC's "fast memory" mode (useWasmFastMemory=true) relies on the
SIGBUS/SIGSEGV handler to convert OOB accesses into wasm traps without
an explicit bounds check. The handler observes the fault and traps the
wasm correctly, but the in-bounds bytes already corrupted by the partial
commit remain in memory. Subsequent reads see wrong data.

Reproducer: spec-tests/memory_trap.wast.js #295. Test 51 of the same
file does i32.store at offset 65535 (1 in-bound byte, 3 OOB bytes);
expected to trap. The trap fires but byte 65535 gets clobbered to 0
before the fault. Later test #295 reads i64 at offset 65528 (covering
bytes 65528..65535) and finds 0x0067666564636261 instead of
0x6867666564636261 -- the assertion against the i64 const trips the
wasm "unreachable" guard.

Force-disable useWasmFastMemory on RISCV64; bounds checking falls back
to the explicit BoundsChecking mode in emitCheckAndPreparePointer,
which checks the access upper bound against the memory size before
issuing any load/store.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
--- a/Source/JavaScriptCore/runtime/Options.cpp
+++ b/Source/JavaScriptCore/runtime/Options.cpp
@@ -804,6 +804,21 @@ void Options::notifyOptionsChanged()
 #endif
 #endif
 
+#if CPU(RISCV64)
+    // The base RISC-V ISA permits a faulting store to commit some of its
+    // bytes before raising the exception (single-copy atomicity is only
+    // guaranteed for naturally-aligned accesses up to XLEN, not for a
+    // store that straddles a page boundary into PROT_NONE). On hardware
+    // that does this (e.g. SiFive U74 in JH7110), JSC's signal-based
+    // bounds check sees the page fault but the in-bounds bytes have
+    // already been corrupted -- subsequent reads return wrong values.
+    // Force explicit bounds checking instead. Reproducer:
+    // spec-tests/memory_trap.wast.js #295 (i32.store at 65535 partially
+    // overwrites byte 65535 before trapping, then i64.load at 65528
+    // sees the corrupted high byte).
+    Options::useWasmFastMemory() = false;
+#endif
+
 #if !CPU(ARM64)
     Options::useRandomizingExecutableIslandAllocation() = false;
 #endif