4 ms·

> JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. Do you

> JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. Do you have numbers to back that up? There certainly have been 1 or more security holes in JITs, but AFAICT most of the browser vulnerabilities have more to with bad (new) APIs. The level where a JIT operates really has nothing to do with the surface syntax of JS, so adding "syntactic sugar" features to JS should have very little impact on JITs. (I'm thinking of things like the class syntax, lexical scope for function literals, etc. Maybe there's a class of additions that I'm missing.)

PaulHoule 7y ago
I am more familiar with Java where the runtime implementations have gone back and forth through various iterations, such as Jazelle and various ways to accelerate Java on ARM, the various Android implementations, etc. What people think is the best choice of tiers to use is always evolving. One factor against JIT's is that modern chips and OS want to set the NX (no execute) bit against the stack and the heap which at least forces attackers into return-oriented programming. To JIT you have to at least partially disable that behavior.
gok 7y ago
> Do you have numbers to back that up? Hm hard to come up with a number that shows JS optimizations are hard, but you can peruse a collection of Javascript engine CVEs: https://github.com/tunz/js-vuln-db https://github.com/tunz/js-vuln-db Notice how many are JIT or optimization issues, or are in esoteric features like async generators or the spread operator.
- Quekid5 7y ago
  That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :). It's interesting how many of those are labeled OOB. Does that mean that we're talking JIT flaws that allow OOB access to memory? Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? I wonder what the performance impact of all JIT code being forced to do bounds-checking would be...
  - saagarjha 7y ago
    > Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? What's the difference between the two? Many JavaScript exploits abuse the interaction between strange features of the language to get around bounds checks (often, because a length was checked but invalidated by later JavaScript executing in an unexpected way, or a bound not forseen as needing a check) leading to an out-of-bounds. And I'm assuming many of these are heap corruptions where someone messes with a length that lets them get out-of-bounds.
    - deleted 7y ago
      [deleted]
    - Quekid5 7y ago
      It's not much of a difference in terms of consequences, but always-on bounds checking could alleviate OOB'ing the JIT at least.

PaulHoule 7y ago

I am more familiar with Java where the runtime implementations have gone back and forth through various iterations, such as Jazelle and various ways to accelerate Java on ARM, the various Android implementations, etc. What people think is the best choice of tiers to use is always evolving. One factor against JIT's is that modern chips and OS want to set the NX (no execute) bit against the stack and the heap which at least forces attackers into return-oriented programming. To JIT you have to at least partially disable that behavior.

gok 7y ago

> Do you have numbers to back that up? Hm hard to come up with a number that shows JS optimizations are hard, but you can peruse a collection of Javascript engine CVEs: https://github.com/tunz/js-vuln-db https://github.com/tunz/js-vuln-db Notice how many are JIT or optimization issues, or are in esoteric features like async generators or the spread operator.

Quekid5 7y ago
That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :). It's interesting how many of those are labeled OOB. Does that mean that we're talking JIT flaws that allow OOB access to memory? Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? I wonder what the performance impact of all JIT code being forced to do bounds-checking would be...
- saagarjha 7y ago
  > Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? What's the difference between the two? Many JavaScript exploits abuse the interaction between strange features of the language to get around bounds checks (often, because a length was checked but invalidated by later JavaScript executing in an unexpected way, or a bound not forseen as needing a check) leading to an out-of-bounds. And I'm assuming many of these are heap corruptions where someone messes with a length that lets them get out-of-bounds.
  - deleted 7y ago
    [deleted]
  - Quekid5 7y ago
    It's not much of a difference in terms of consequences, but always-on bounds checking could alleviate OOB'ing the JIT at least.