Control-Flow Integrity in V8

With jitting runtimes like V8 often the root cause of the exploit is a logical error in code generation that leads to the sandboxed code to get a read/write gadget into memory outside the sandbox. Rewriting the jit in Rust might help eliminate those kinds of issues, but it's still entirely possible they would happen.

A JIT is a machine for turning logic bugs into memory unsafety. Rewriting a JIT in Rust won't eliminate logic bugs and won't guarantee memory safety for the binary output of the JIT (as distinct from the JIT implementation itself).

> Is it measurably helping eliminate this class of issue?

No.

A JIT is a compiler.

The compiler itself would be memory-safe, but not the compiled output.

The JS runtime and JIT are still entirely C++ and assembly, afaik. I'm not sure we'd ever see them migrate Spidermonkey to Rust.

Most of these techniques are engineered to not cause much of a performance degradation. Otherwise there would not be much uptake. Also they are often implemented in compilers which produce native binaries so the impact is low.

The mitigations for the various hardware sidechannel attacks discovered in the past year have a bit larger impact. But you don't need these at all on your local computer, only in shared environments.

As a rule of thumb each mitigation usually costs a single digit percentage, seldom double digit. Of course in a system multiple mitigations will be at play but the impact should be far below 100%.

The performance impact of scripting languages, interoperable web standards and bad implementations are far worse :)

> Is there a reasonable way to estimate how much performance could be gained if we operated in a hypothetical universe where we never ever had to worry about security?

Not really, no. In the limit of a theoretically perfect implementation, the performance overhead of security is zero (except to the extent that you count cryptography, but that's distinct from CFI/RCE/memory-corruption/etc-style security). The practical overhead basically comes from defence-in-depth to insure that imperfect implementation don't break security, and there's not in general any fundamental reason why imperfection A is common problem that needs to be mitigated, but imperfection B is a stupid corner case deserving of "well, don't do that then". Also we essensially -by-definition don't have a theoretically perfect implementation to compare against, so we can't even estimate the zero-overhead point with any confidence.

> how much performance could be gained

One place to look at would be TLS perf.

Network latency, encryption compute.

It depends on the solution. The paper referenced in the article suggests "≈ 0%-1.94% in SPEC CPU2017 and ≈0%-1.92% in real-world applications"..., which is extremely impressive. In my practice, the costs are generally much higher.

paper: https://arxiv.org/abs/2303.16353