4 ms·

A JIT is not, by itself, unsafe. The problem is that maintaining the complex set of constraints and invariants necessary to generate both safe and performant co

A JIT is not, by itself, unsafe. The problem is that maintaining the complex set of constraints and invariants necessary to generate both safe and performant code is extremely difficult, and one slip-up can mean generating code that breaks some invariant and escapes a safety boundary. You can have simple JITs that are completely safe: they generate code to bounds- and type-check unconditionally and avoid fragile optimizations. But, if you want to go faster, you have to start dropping checks and performing aggressive optimizations (peephole, inlining, object layout tricks, …) and every new optimization is an opportunity to make a mistake. PAC and friends are an effort to make the hardware support certain checks more efficiently. But again, as they are an extra check, there’s always the chance that they’ll be slower than the unchecked alternative; if so, you can bet that one day an engineer looking to get a 0.5% perf gain will try removing those checks (“safely”) and we’ll be back to square one.

astrange 4y ago
> A JIT is not, by itself, unsafe. The problem is that maintaining the complex set of constraints and invariants necessary to generate both safe and performant code is extremely difficult, and one slip-up can mean generating code that breaks some invariant and escapes a safety boundary. I mean… isn't that what unsafe means? A "memory-unsafe" language means a language it's possible to make a mistake in, not one where memory errors happen all the time.
- nneonneo 4y ago
  The statement that a JIT is itself unsafe is tantamount really to saying that “compilers are unsafe” or even “interpreters are unsafe”. All a JIT really is is a way to execute code. As an example, the Rust compiler has some [60+ open unsoundness bugs](https://github.com/rust-lang/rust/labels/I-unsound https://github.com/rust-lang/rust/labels/I-unsound), meaning that there are many, many ways that a sequence of ostensibly safe code could be compiled into an unsafe executable (i.e. one which exhibits an unsafe behaviour like a double free). If you allowed malicious users to run Rust code on your machine, even without unsafe features and a limited standard library (as the case with JS in the browser), they could take advantage of these compiler bugs to escape Rust’s safety guarantees and whatever protections you put in place. And these bugs exist even though Rust itself is a safe language, and even though much of the Rust compiler is itself written in a safe language.

astrange 4y ago

> A JIT is not, by itself, unsafe. The problem is that maintaining the complex set of constraints and invariants necessary to generate both safe and performant code is extremely difficult, and one slip-up can mean generating code that breaks some invariant and escapes a safety boundary. I mean… isn't that what unsafe means? A "memory-unsafe" language means a language it's possible to make a mistake in, not one where memory errors happen all the time.

nneonneo 4y ago
The statement that a JIT is itself unsafe is tantamount really to saying that “compilers are unsafe” or even “interpreters are unsafe”. All a JIT really is is a way to execute code. As an example, the Rust compiler has some [60+ open unsoundness bugs](https://github.com/rust-lang/rust/labels/I-unsound https://github.com/rust-lang/rust/labels/I-unsound), meaning that there are many, many ways that a sequence of ostensibly safe code could be compiled into an unsafe executable (i.e. one which exhibits an unsafe behaviour like a double free). If you allowed malicious users to run Rust code on your machine, even without unsafe features and a limited standard library (as the case with JS in the browser), they could take advantage of these compiler bugs to escape Rust’s safety guarantees and whatever protections you put in place. And these bugs exist even though Rust itself is a safe language, and even though much of the Rust compiler is itself written in a safe language.