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