aarch64: linear-memory load/store emit NO bounds check and --safety-bounds is a no-op (all modes byte-identical) — OOB reads/writes up to 4GiB past the guest memory instead of trapping

[avrabe]

Summary

The new aarch64 linear-memory lowering (#855, v0.51.0) emits no bounds check at all, and --safety-bounds is a no-op on the aarch64 backend — none, software, mask, and mpu all produce byte-identical output. A guest i32.load/i32.store becomes a bare add x9, x28, w0, uxtw; ldr/str [x9], so any out-of-bounds guest address is dereferenced directly against host memory instead of trapping. wasmtime traps the same access.

Because the address is zero-extended (uxtw), a guest address of 0xFFFFFFFF reaches x28 + 4 GiB − 1 — i.e. the guest can read and write up to 4 GiB past its linear memory. The store form gives an arbitrary-write primitive.

This is the "flag exists but doesn't enforce" class (cf. #651 mask-mode, kiln#411) — on a backend that, as of v0.51.0, is advertised as running real WASM modules.

Reproduction (synth 0.51.0)

(module (memory 1) (func (export "f") (param i32) (result i32) (i32.load (local.get 0))))

synth compile t.wat -b aarch64 -n f --relocatable --safety-bounds software -o t.o
llvm-objdump -d --triple=aarch64 t.o

0: 8b204389   add  x9, x28, w0, uxtw     ; x28 = linear-memory base
4: b9400129   ldr  w9, [x9]              ; <-- no bounds check, no trap path
8: aa0903e0   mov  x0, x9
c: d65f03c0   ret

All four modes are byte-identical (same md5 for --safety-bounds none|software|mask|mpu), so the flag has no effect on this backend:

none      78af70bc77f24e0145c992652bff89fe
software  78af70bc77f24e0145c992652bff89fe
mask      78af70bc77f24e0145c992652bff89fe
mpu       78af70bc77f24e0145c992652bff89fe

The store form is identical (add x9, x28, w0, uxtw; str w1, [x9]) — an unchecked write.

Executed natively (arm64 host, MAP_JIT, x28 = a real memory region), module declares (memory 1) = 64 KiB:

guest address	synth (aarch64)	wasmtime
65532 (in bounds)	0	0
65536 (1 byte past)	0 (reads host memory)	trap (out of bounds)
100000	0 (reads host memory)	trap
−1 (0xFFFFFFFF)	-829685755 (garbage from x28+4GiB−1)	trap

Why it matters

• Silent: no diagnostic, no trap — the guest just reads/writes outside its memory.
• --safety-bounds implies a choice of enforcement strategy; on aarch64 every mode (including software and mpu) silently degrades to none.
• With uxtw zero-extension the reachable window is the full 4 GiB above x28, in both directions of access (load = disclosure, store = arbitrary write).

Suggested fix

Emit the bounds check on the aarch64 load/store path (the memory-size register/limit compare + trap, mirroring the thumb-2 software mode), and make --safety-bounds select the strategy on aarch64 — or, if aarch64 is not yet meant to enforce, hard-error on --safety-bounds software|mask|mpu for -b aarch64 rather than silently accepting the flag and emitting unchecked accesses.

Context

Found while extreme-testing the new v0.51.0 aarch64 surface. The rest of the new lowering is solid — I executed sub-word load/store sign/zero-extension + truncation + adjacent-byte safety, unaligned access, aliasing stores, high local pressure mixed with memory, a 4000-iteration loop-over-memory array sum, and a 1000-node pointer-chasing linked-list walk: all bit-exact vs wasmtime. This is specifically the bounds/--safety-bounds gap. (Separately: select is not yet lowered on aarch64, which blocks branchless algorithms — minor, mentioning in case it's in scope for the same milestone.)

[avrabe]

Fixed in v0.52.0 (published: crates.io + npm). aarch64 linear-memory accesses now bounds-check by default — an OOB access traps (brk) exactly where wasmtime traps, verified against your exact table (65532 in-bounds matches; 65536 / 100000 / 0xFFFFFFFF all trap). --safety-bounds is real now: software = the enforcing default, none = explicit opt-out, and mask/mpu hard-error rather than silently degrading. The byte-identical-md5 symptom is gone (md5(none) ≠ md5(software)), and a mode-difference assertion is part of the gate so a future silent no-op fails loudly. Non-vacuity was proven independently by the release's cold review: the same differential fails with 15 failures on a v0.51.0 binary. Thank you for the executed table — the lane was built directly against it.

[avrabe]

Verified fixed on v0.52.0 — thank you, that was fast. Re-tested natively (arm64, MAP_JIT, x28 = a real linear-memory region) against wasmtime.

The fix is precise, not just present:

0: 529fff89  mov  w9, #0xfffc      ; 65532 = 65536 - 4  (access width folded in)
4: 6b09001f  cmp  w0, w9
8: 54000049  b.ls 0x10
c: d4200000  brk  #0               ; trap path
10: 8b204389 add  x9, x28, w0, uxtw
14: b9400129 ldr  w9, [x9]

Execution-verified, all matching wasmtime (22 checks):

case	limit	result
i32.load 32-bit	65532	65532 ok, 65533/65536/100000/−1/INT_MIN trap
i32.load8_u	65535	65535 ok, 65536 traps
i32.load16_u	65534	65534 ok, 65535 traps
i64.load	65528	limit mov w9,#0xfff8 — correct 8-byte width
i32.load offset=16	—	static offset folded in: 65516 ok, 65517 traps
i32.store	65532	write primitive blocked (65533/100000/−1 trap)
(memory 2)	131068	scales with page count
in a loop	—	re-checked per iteration (n=16384 ok, n=20000 traps)

Also good: --safety-bounds is no longer a no-op — none (4 instrs, unchecked) and software (8 instrs, checked) now differ, and mask/mpu are honestly rejected on aarch64 rather than silently degrading. That's exactly the right shape.

I've added a standing execution guard on our side (in addition to the static one), so a regression that removes the check surfaces immediately as an OOB-returns-a-value divergence.

Two small follow-ons noticed while testing (not blockers, mentioning for the milestone): select and i32.wrap_i64 aren't lowered on aarch64 yet — select blocks branchless algorithms, and wrap_i64 blocks reading an i64 memory value back as i32. Everything else I threw at the new memory path (sub-word sign/zero-extension, store truncation + adjacent-byte safety, unaligned, aliasing stores, 10-live-locals + memory scratch, 4000-iteration loop-over-memory, 1000-node pointer chase) is bit-exact vs wasmtime.

[avrabe]

Follow-up: I ran a deep adversarial pass on the fix rather than stopping at "a check exists" — 12 attack classes aimed at the places bounds checks usually fail. No escape found. Recording it so the fix has evidence behind it, plus one latent hazard for the future.

Attacks that found nothing (all match wasmtime, executed natively):

#	Attack	Result
1	Huge static offset= (65536, 1e6, 2³¹, 2³²−1) overflowing the limit	all trap
4	Computed address (a*4)+(b&0xff) — is the checked value the accessed value?	trap boundary exact (16383+12 traps)
5	Address loaded from memory (load-of-load)	second load checked too
6	Shifted/scaled a<<2 incl. u32 wraparound (2³⁰<<2 = 0)	matches wasmtime
7	Negative/wrapping arithmetic a-b below zero → ~4 GiB	traps
8	Many accesses in one function — is only the first guarded?	4 accesses → 4 brk guards, boundary exact
9	Access ordering after a would-trap access	correct
10	Constant addresses (0 … 999999) — optimizer eliding the guard?	guard kept on every one; const-OOB traps
11	--no-optimize vs default — check dropped under optimization?	guard present in both, OOB traps
12	Multi-memory (memory 1)(memory 2)	memidx-0 access uses memory 0's limit (correct); an access to memidx 1 is honestly declined — no wrong-memory/wrong-limit risk

One latent hazard, not a bug today: the limit is a compile-time constant (mov w9,#0xfffc). That's sound right now only because memory.grow/memory.size are not lowered on aarch64 — nothing can change the size. When grow lands, the check must become dynamic (read the current size), or a grown memory will still be checked against the original limit — the check would then reject valid post-grow addresses (and, if the limit were ever derived differently, could under-check). Worth wiring into the grow work when it happens.

Our standing execution guard now carries the five sharpest of these shapes (34 checks total), so a regression in any of them surfaces immediately.