3 ms·
> 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 eng
by 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 agoThat'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 agoIt's not much of a difference in terms of consequences, but always-on bounds checking could alleviate OOB'ing the JIT at least.