5 ms·
> Similarly, disabling the JIT compilers would also only be a partial solution: historically, roughly half of the bugs discovered and exploited in V8 affected o
by frankjr 3y ago
> Similarly, disabling the JIT compilers would also only be a partial solution: historically, roughly half of the bugs discovered and exploited in V8 affected one of its compilers while the rest were in other components such as runtime functions, the interpreter, the garbage collector, or the parser. 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).
If you're willing to take the performance hit, Chromium actually allows you to disable JIT easily in the Settings and add exceptions for certain sites. Open the Settings and search for V8 Optimiser.
- vlovich123 3y ago> while the rest were in other components such as runtime functions, the interpreter, the garbage collector, or the parser Notably memory safe languages wouldn't really help with the garbage collector since it would have to use unsafe Rust & the confusion about lifetime would still exist or you'd be using something like Java/C# where you're just relying on the robustness of that language's runtime GC. However, the runtime functions, interpreter and parser would be secured by something like Rust & I fail to see how well-written Rust would introduce a 1.5-10x overhead.
- deleted 3y ago[deleted]
- fngjdflmdflg 3y agoI think the key is: >and removing JIT compilers If you read the article it makes more sense.
- kaba0 3y agoThat’s not quite true. It only depends on what level of abstraction are you willing to do — you can write a runtime with GC entirely in safe rust (or a managed language).
- dadrian 3y agoIt doesn't matter if the JIT itself is written in a memory-safe language or not if you're exploiting miscompiled JIT output. If the machine code emitted by a JIT is wrong, it can be exploited regardless of if the JIT itself is memory safe or not.
- mike_hearn 3y agoSurprisingly, it does matter! The key abstraction here is partial evaluation combined with memory safe languages. Look at how the JVM world does it with GraalJS (or GraalPython or the other langs). This approach eliminates the sorts of vulnerabilities V8 is talking about, because the semantics of the language are defined as a memory-safe interpreter, which is then converted to JIT compiled code directly by having the compiler treat interpreter data structures as constants for the constant folding passes. This gives you a 1-2 win: 1. The example given at the top of the blog post wouldn't be exploitable in interpreter mode in GraalJS, because the VM intrinsic would be written in Java and thus bounds checked. 2. It's also not exploitable once JIT compiled, because the intrinsic and its bounds check has been inlined into the user code function and optimized as a unit (meaning the bounds check might be removed if the compiler can prove that the user's implementation of ToNumber doesn't modify the size). GraalJS has nearly V8 levels of peak performance, so this technique doesn't require big sacrifices for server workloads, and client workloads where latency matters more are now a focus of the team. In this way you can build a high performance JS engine that still has tight security. It supports code sandboxing also. (Disclosure: I do part time work for Oracle Labs and sit next to some of the people doing that work)
- kaba0 3y agoI thought the abstraction I wrote sort of implied an interpreted mode for the runtime, no JIT compilation. Apologies for not being clear.
- The_Colonel 3y agoThat's just trivially true given all these languages are Turing-complete.
- azakai 3y agoThe 1.5-10x overhead part is not talking about Rust, but about disabling JITs.
- o11c 3y agoMany memory-safe languages would be fine. Only languages with the particular narrow opinions of Rust would likely be vulnerable to this.
- zaphirplane 3y agoI’m glad the terminology for Rust evolved from safe language to memory safe language.
- orangepanda 3y agoDoes Safari in Lockdown Mode do anything more than just disabling JIT?
- madars 3y agoYes, it also disables WASM, MP3 decoding, gamepad API, JPEG 2000, SVG fonts, PDF previews, WebGL, Speech Recognition API, Web Audio API. Pretty much web as it was meant to be ;-) https://9to5mac.com/2022/07/25/lockdown-mode-ios-16-restricts-web-browsing/ https://9to5mac.com/2022/07/25/lockdown-mode-ios-16-restrict...
- thefounder 3y agoI think you mean the html not the web
- pjmlp 3y agoI still remember when that was all the Web offered, the glory days of HTML 2.0.
- grishka 3y ago> would significantly reduce the engine's performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks). And the downside being? Seriously, JS was never meant to be performant. In the real world, it's very rarely used for anything computationally intensive.
- zamadatix 3y agoPower usage
- grishka 3y agoJIT compilation isn't free either.
- troupo 3y agoGoogle already says that 2.5 seconds to Largest Contentful Paint is fast: https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html https://blog.chromium.org/2020/05/the-science-behind-web-vit... Now multiply that by 1.5x.
- grishka 3y agoRendering pages server-side and avoiding 5-megabyte bundles might help with that. JIT and other browser-side performance optimizations just delay the problem anyway. The culture around web development needs to change.
- jrajav 3y agoVery curious what your unique definition of 'computationally intensive' is, that manages to not include one of the most significant computational workloads worldwide, both in terms of absolute volume and impact on human productivity. Namely, web browser rendering performance.
- grishka 3y agoHuh? The rendering is part of the browser itself. It's not like JS has to run every frame to put the pixels onto the screen. Making ajax requests and doing things to the DOM tree isn't a "computational workload" because there's hardly any computation happening in that JS code.