[IainIreland]

The whole point is that the sandbox is an approach that can be used in JIT code, where Rust doesn't help.

Take the fizzbuzz example with a missing bounds check. Rust can't prevent you from generating JIT code that omits a bounds check on an array and reads/writes out-of-bounds. The sandbox doesn't prevent out-of-bounds reads/writes, but it guarantees that they will only be able to access data inside the sandbox.

This means that logic bugs in the JIT compiler are no longer immediately exploitable. They must be combined with bugs in the sandbox implementation. The article's claim is that, unlike compiler bugs, sandbox bugs tend to be amenable to standard mitigation techniques.

This article isn't dismissing the value of memory-safe languages. It's identifying a problem space where current memory-safe languages can't help, and providing an alternative solution. Currently, every browser JS engine is written in C++, in part because Rust doesn't solve the big correctness problems. If the sandbox approach works, then using Rust for other parts of the engine becomes more appealing.

[vlovich123]

To be clear. I have no issue with the sandboxing as a technique. It's perfectly valid and a good idea. My issue is that sandbox escapes are significantly easier than they should be due to the C++ runtime. Rust 100% would help mitigate sandbox escapes more effectively even as the codebase evolves. We know through lots of practical experience that "standard mitigation techniques" for C++ don't actually work all that well (there's at least about an order of magnitude difference in number of exploits possible between that & Rust).