Writing Memory Safe Jit Compilers

My impression is that JIT bugs would be similar to a bug in the rust compiler. No system is perfect and the rust compiler is just as susceptible to bugs as a jit engine is.

The difference being that your rust programs aren't usually written by malicious people. The goal is to prevent accidental memory safety issues not intentional ones. In contrast the JIT compiler is compiling code made by the adversary.

I think the issue they are stating is the errors are either in the optimizer (needing alive2 equiavlent) or in the analysis passed. A memory safe language (in this case JavaScript) can convince a buggy compiler to do things out of spec. The attack surface of the interactions of the compiler might be more interesting or larger than of the compiler itself

Rust only guarantees it up to bugs in the analysis though, which is usually okay for rust, but not for truly adversarial inputs (JavaScript)

The better comparison might be ebpf, where you take the output of one compiler, then verify with a second compiler, then compile with a third compiler, so there are that many more gates you need to pass to get malicious input to produce exploitable output, while still getting speed

The linked tech talk ("Deoptimization [...]") goes into a lot more detail -- worth a watch if you find this stuff interesting:

https://www.youtube.com/watch?v=pksRrON5XfU

Not exactly. It's the nature of a sandbox that it doesn't remove bugs, it only reduces their blast radius. The Truffle architecture actually removes bugs by changing how you write the language VM to begin with.

(I wrote the article).

The optimizations do have to be correct. However, there are some significant factors that make it a lot easier in the Truffle architecture:

1. The optimizations are themselves implemented in a language with memory safety and lots of static analysis tools, so they're just less likely to be buggy for the usual reasons.

2. Most of the complex optimizations that matter for a language like Javascript or Python are implemented in the interpreter, which is then partially evaluated. In a classical language VM complex optimizations like PICs, specialization, speculation etc are all hand coded in C++ by manipulating compiler IR. It's a very unnatural way to work with a program. In the Truffle architecture they're implemented in normal Java in relatively straight-line logic, so there's just far fewer ways to mess up.

3. The intrinsics are also all written in a memory safe language. Buggy intrinsics are a common cause of compiler errors.

It is nonetheless true that at some points the program is transformed, and those transforms can have bugs. Just like how languages with memory safety and strong standard libraries don't eliminate all bugs, just a lot of them. It's still a big upgrade in correctness, I think.

That's what I got from reading the article; the takeaway is that all its doing to solve the types of problems V8 has is by shifting the complications beneath another layer. All the problems and challenges and potential for mistakes still exist, they're just within GraalVM now.

Which is not without real benefit, of course; it's a lot easier to build and secure one genericized VM runtime toolkit than it is to rebuild everything from scratch for every single language runtime like V8 that might need to exist. It's far better to competently solve the difficult problem once than to try to competently solve it over and over and over.

No, that's not what it's arguing.

Basically it's easier to implement optimizations correctly if you're expressing them in regular logic instead of hand-written graph manipulations. The underlying approach is fundamentally different.

It is! https://news.ycombinator.com/item?id=7061913