5 ms·

Control-Flow Integrity in V8

47 points by unripe_syntax 3y ago

ashvardanian 3y ago
The article mentions Guarded Control Stack (GCS) in Arm v9.4. Anyone familiar with existing CPUs supporting those extensions?
Waterluvian 3y ago
Reading this got me wondering about the bigger picture trade-off between security and performance. 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?
- ashvardanian 3y ago
  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 https://arxiv.org/abs/2303.16353
- MailNerd 3y ago
  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 :)
- a1369209993 3y ago
  > 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.
- paulddraper 3y ago
  > how much performance could be gained One place to look at would be TLS perf. Network latency, encryption compute.
Waterluvian 3y ago
“V8 exploits typically follow a similar pattern: an initial bug leads to memory corruption…” naturally gets me wondering about Firefox and Rust. Is it measurably helping eliminate this class of issue? Too soon to tell?
- treyd 3y ago
  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.
- hovav 3y ago
  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).
  - infogulch 3y ago
    Agreed. But the way you put it makes me wonder how many memory safety vulns have been found in JIT implementations (not the machine code they output).
  - nextaccountic 3y ago
    Okay, but in this case software verification like with Coq or F* could help
    - hovav 3y ago
      Yes! See, e.g., Fraser Brown et al., "Towards a Verified Range Analysis for JavaScript JITs," in proc. PLDI 2020, https://www.cs.utexas.edu/~hovav/dist/vera.pdf https://www.cs.utexas.edu/~hovav/dist/vera.pdf
- paulddraper 3y ago
  > 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.

47 points by unripe_syntax 3y ago

The article mentions Guarded Control Stack (GCS) in Arm v9.4. Anyone familiar with existing CPUs supporting those extensions?

Waterluvian 3y ago

Reading this got me wondering about the bigger picture trade-off between security and performance. 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?

ashvardanian 3y ago
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 https://arxiv.org/abs/2303.16353
MailNerd 3y ago
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 :)
a1369209993 3y ago
> 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.
paulddraper 3y ago
> how much performance could be gained One place to look at would be TLS perf. Network latency, encryption compute.

Waterluvian 3y ago

“V8 exploits typically follow a similar pattern: an initial bug leads to memory corruption…” naturally gets me wondering about Firefox and Rust. Is it measurably helping eliminate this class of issue? Too soon to tell?

treyd 3y ago
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.
hovav 3y ago
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).
- infogulch 3y ago
  Agreed. But the way you put it makes me wonder how many memory safety vulns have been found in JIT implementations (not the machine code they output).
- nextaccountic 3y ago
  Okay, but in this case software verification like with Coq or F* could help
  - hovav 3y ago
    Yes! See, e.g., Fraser Brown et al., "Towards a Verified Range Analysis for JavaScript JITs," in proc. PLDI 2020, https://www.cs.utexas.edu/~hovav/dist/vera.pdf https://www.cs.utexas.edu/~hovav/dist/vera.pdf
paulddraper 3y ago
> 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.