With jitting runtimes like V8 often the root cause of the exploit is a logical error in code generation that leads to the sandboxed code to get a read/write gadget into memory outside the sandbox. Rewriting the jit in Rust might help eliminate those kinds of issues, but it's still entirely possible they would happen.
A JIT is a machine for turning logic bugs into memory unsafety. Rewriting a JIT in Rust won't eliminate logic bugs and won't guarantee memory safety for the binary output of the JIT (as distinct from the JIT implementation itself).
Agreed. But the way you put it makes me wonder how many memory safety vulns have been found in JIT implementations (not the machine code they output).
Re:Control-Flow Integrity in V8
by nextaccountic on Monday October 09, 2023 @05:25PM
(#37825716)
Okay, but in this case software verification like with Coq or F* could help
Yes! See, e.g., Fraser Brown et al., "Towards a Verified Range Analysis for JavaScript JITs," in proc. PLDI 2020, https://www.cs.utexas.edu/~hovav/dist/vera.pdf
Re:Control-Flow Integrity in V8
by paulddraper on Monday October 09, 2023 @05:06PM
(#37825480)
> Is it measurably helping eliminate this class of issue?
No.
A JIT is a compiler.
The compiler itself would be memory-safe, but not the compiled output.
naturally gets me wondering about Firefox and Rust. Is it measurably helping eliminate this class of issue? Too soon to tell?