1398266 - (X-only) Take advantage of Execute Only Memory (XOM)

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P5)

Description

[Tom Ritter [:tjr]]

If we have our JIT emit in XOM memory, we can close off attack vectors that rely on abusing the JIT to produce ROP gadgets. (This attack vector only makes sense once constant blinding in Bug 1376819 is in place though.)

An attacker could spew a ton of JIT instructions out at random, hoping to create ROP gadgets by dumb luck. They use a read primitive to find the gadgets they need once the JIT emits them. XOM would block that.

XOM is not limited to the JIT, it would be beneficial for the process as a whole, and would help reinforce a selfrando approach (Bug 1371002)



Unfortunately, the only processor as of this writing that supports XOM is Arm64 so while we could do this for Android, we couldn't do it for desktop. The kernel seems to have support for XOM, but when you try and use it without hardware support it just becomes RX. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62b5f7d013fc455b8db26cf01e421f4c0d264b92)

So this a far-future goal, but I wanted to jot it down to spur discussion (I'm not super clear on what the timeline for XOM hardware is, or a myriad of the other considerations in this) and not lose the idea.

Comment 1

[Lars T Hansen [:lth]]

Our WebAssembly implementation uses signal handlers for bounds checking traps on 64-bit systems as this is a significant performance win, and I expect we'd really like to do that on ARM64 too.  Those signal handlers currently need to disassemble the trapping access so as to set up correct result values in registers, ie, they need to read the executable segment.  If XOM can be temporarily remapped as readable we may be able to do what we need.  However, if the remapping is non-executable+readable we must deal with the fact that the code is shared among many threads, and we'd need to safely park all of the threads before we could do that kind of remapping.

(Eg, grep for HandleMemoryAccess in js/src/wasm/WasmSignalHandlers.cpp.)

Storing "enough" information about the trapping access in side tables to avoid disassembly might be possible, though I'd be a little concerned about the memory cost of that.  Data needed, at a minimum.

Comment 2

[Luke Wagner [:luke]]

(In reply to Lars T Hansen [:lth] from comment #1)
> Those signal handlers currently need to disassemble the trapping access so as to set up correct
> result values in registers,

Actually, I think that disassembly stuff can be removed: it was just meant to work around misreported faulting-address to handle an asm.js+SIMD.js corner case that can't occur with wasm.  I'll file a bug to remove if that's the case.

Comment 3

[Luke Wagner [:luke]]

Oops, I spoke too soon; the disassembling is useful for asm.js in general to avoid needing to store the destination register.  Anyhow we could work around that in a number of ways and, in time, asm.js opts will just be removed.

Comment 4

[Tom Ritter [:tjr]]

XOM may be emulatable with Intel MPK: https://github.com/intel/xom-switch

Comment 5

[Lars T Hansen [:lth]]

"When binaries has data embedded in the middle of code, xom-switch may crash."  Not a showstopper of course, but we do embed data in the code segment, and we do generate code that more or less depends on that being possible (on arm-ish systems we limit the distance from a load-immediate instruction to the immediate data, for example); it'll be some work to reengineer that.

Comment 6

[Nicolas B. Pierron [:nbp]]

Intel MPK has a cheap way which only involve to toggle data-read accesses of the memory, so we could toggle it on/off around the switch table accesses.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Unfortunately, the only processor as of this writing that supports XOM is Arm64 so while we could do this for Android, we couldn't do it for desktop.

The pending release of AArch64 based Macs will be changing this.

Comment 9

[Nicolas B. Pierron [:nbp]]

This work is being re-rooted under JIT Spray mitigation project, but without constant blinding (Bug 1376819) requirement.