Hacker News Reader

Comment by frankjr | Hacker News Reader

> 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.

View on HN

> 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.

I think the key is:

>and removing JIT compilers

If you read the article it makes more sense.

That’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).

It 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.

I thought the abstraction I wrote sort of implied an interpreted mode for the runtime, no JIT compilation. Apologies for not being clear.

That's just trivially true given all these languages are Turing-complete.

Surprisingly, 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)

Yup you can write a garbage collected interpreter for a programming language with no unsafe code at all, even for languages that have complex data structures like doubly linked lists in them.

Using something like a slotmap to store the languages objects in is what I would do, and your GC would just involve removing values from the map after marking everything that's reachable.

The popular slotmap crate on crates.io does contain unsafe code but nothing about the data structure inherently requires unsafe.

The 1.5-10x overhead part is not talking about Rust, but about disabling JITs.

Many memory-safe languages would be fine. Only languages with the particular narrow opinions of Rust would likely be vulnerable to this.

I’m glad the terminology for Rust evolved from safe language to memory safe language.

Does Safari in Lockdown Mode do anything more than just disabling JIT?

Yes, 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-restrict...

I think you mean the html not the web

I still remember when that was all the Web offered, the glory days of HTML 2.0.

> 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.

Power usage

JIT compilation isn't free either.

Google already says that 2.5 seconds to Largest Contentful Paint is fast: https://blog.chromium.org/2020/05/the-science-behind-web-vit...

Now multiply that by 1.5x.

Rendering 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.

Very 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.

Huh? 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.

Only if we could have HTMX or Turbo that doesn't rely on JS. And then for 95%+ of website, most JS code are used for tracking and ads.

> Seriously, JS was never meant to be performant.

If you mean “wasn’t originally meant”, that might be true. But it’s been meant to be performant for quite a long time, with huge investments behind the realization of that intent.

It’s fine if you have nostalgia for whatever you think was the original vision behind JS. But that hasn’t been the operating vision for it for many years.

it’s really important so that Facebook can be fast (Facebook is still slow)

Reply on news.ycombinator.com