blob: 294693bcf853a68f184c3a31528ed1e029a6a529 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
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
|
