> Using a memory-safe language for these components and removing JIT compilers could work, but would significantly reduce the engine's performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks)
I don't get it, why the dichotomy between "no JIT" and "sandboxed JIT"? Isn't the not also the option of producing JITted code with safety guarantees, similarly to how the Rust compiler generates code with safety guarantees?
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
> Although being written in Java does improve memory safety, we just saw that rewriting V8 in a safe language wouldn’t help with the types of bugs V8 is trying to solve and so we would intuitively expect that GraalJS must suffer from the same classes of bugs. Yet, it doesn’t.
Essentially it exchanges the bugs of a V8 engine for the bugs of the GraalVM, right?
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.
Yeah I wonder if there has been much work on formal verification here (including of compiler passes). I know the LLVM team have done some interesting work on verifying LLVM passes using the Alive2 tool for example.
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.
I don't think this is actually memory-safe. It sounds like the JavaScript-specific parts of the VM are untrusted, i.e. bugs in it won't violate memory safety. But the core GraalVM compiler and its optimizations would still have to be trusted (or if not, the post doesn't explain why not).
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.
I think the _copy-and-patch_ approach [0] is probably the best compromise here.
You get many of the guarantees of compiled code (strong correctness, reduced mismatch between interpreter vs JIT semantics, etc.), while still being very close to native performance.
In fact, Python is already moving in that direction: the new bytecode-based copy-and-patch JIT in Python 3.13 shows correct results even before heavy performance tuning.
So to me this seems like a very promising road: I wonder how practical this is if the base language is not C/C++ but Rust (or any kind of memory safe language).
Wish they'd go into more detail about these Futamura projections and how the partial evaluation is implemented. I get it at a conceptual level but I'm still not confident enough to implement one myself.
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 said it "protects" against bugs, not that it "removes" them. The Truffle architecture removes mismatches between JIT and interpreted code (when it doesn't have bugs itself, which is not guaranteed either), but it doesn't remove runtime or object model logic errors that affect both.
I love the work being done by GraalVM team, and the ones that predated it like MaximeVM and JikesRVM, proving that it is possible to use safer languages for all layers of compiler development, instead of the usual cargo cult of what is supposed to work.
I think this is exactly the same approach PyPy used 15 or so years ago! Partially evaluate the language runtime
It is! https://news.ycombinator.com/item?id=7061913
From https://v8.dev/blog/sandbox
> Using a memory-safe language for these components and removing JIT compilers could work, but would significantly reduce the engine's performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks)
I don't get it, why the dichotomy between "no JIT" and "sandboxed JIT"? Isn't the not also the option of producing JITted code with safety guarantees, similarly to how the Rust compiler generates code with safety guarantees?
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
> Although being written in Java does improve memory safety, we just saw that rewriting V8 in a safe language wouldn’t help with the types of bugs V8 is trying to solve and so we would intuitively expect that GraalJS must suffer from the same classes of bugs. Yet, it doesn’t.
Essentially it exchanges the bugs of a V8 engine for the bugs of the GraalVM, right?
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.
Yeah I wonder if there has been much work on formal verification here (including of compiler passes). I know the LLVM team have done some interesting work on verifying LLVM passes using the Alive2 tool for example.
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.
I don't think this is actually memory-safe. It sounds like the JavaScript-specific parts of the VM are untrusted, i.e. bugs in it won't violate memory safety. But the core GraalVM compiler and its optimizations would still have to be trusted (or if not, the post doesn't explain why not).
(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.
I think the _copy-and-patch_ approach [0] is probably the best compromise here.
You get many of the guarantees of compiled code (strong correctness, reduced mismatch between interpreter vs JIT semantics, etc.), while still being very close to native performance.
In fact, Python is already moving in that direction: the new bytecode-based copy-and-patch JIT in Python 3.13 shows correct results even before heavy performance tuning.
So to me this seems like a very promising road: I wonder how practical this is if the base language is not C/C++ but Rust (or any kind of memory safe language).
[0] https://arxiv.org/abs/2011.13127
Wish they'd go into more detail about these Futamura projections and how the partial evaluation is implemented. I get it at a conceptual level but I'm still not confident enough to implement one myself.
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
The V8 sandbox doesn't just protect against JIT issues, it also protects against logical issues in the runtime and object model.
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 said it "protects" against bugs, not that it "removes" them. The Truffle architecture removes mismatches between JIT and interpreted code (when it doesn't have bugs itself, which is not guaranteed either), but it doesn't remove runtime or object model logic errors that affect both.
I love the work being done by GraalVM team, and the ones that predated it like MaximeVM and JikesRVM, proving that it is possible to use safer languages for all layers of compiler development, instead of the usual cargo cult of what is supposed to work.
真是我需要的，太感谢了