Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JIT-Less V8

v8.dev

Post reply on HN
Print view View original

81–90 of 117 posts

Re: JIT-Less V8

#81

Post by bjourne »

pitaj wrote: post #39
bjourne wrote: post #33

Earlier quoted context omitted.

But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.

Yes, but when pre-compiling, you implicitly trust the code. JITs like V8 are used to execute arbitrary code on your device, where such an exploit is much more harmful.

Untrue. Dart code for example is AOT compiled but untrusted. Various Javascript implementations are also AOT but also supposed to be used for untrusted code.

Re: JIT-Less V8

#82

Post by gok »

kllrnohj wrote: post #78
gok wrote: post #62

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-cli…

> The security implications of RWX memory are just so bad Such as? Any practical examples here? Code executions is code execution. RWX just lets you execute faster code, it doesn't give you any privileges or permissions you didn't otherwise already have.

https://www.jaybosamiya.com/blog/2019/01/02/krautflare/

Re: JIT-Less V8

#83

Post by stefan_ »

kllrnohj wrote: post #80
stefan_ wrote: post #26

Earlier quoted context omitted.

Meltdown and Spectre are only possible in the browser because the JIT allows you to write JavaScript that you know is then compiled (JITed) into a very tight assembly loop. Same for Rowhammer.

That's not really a good argument. Taken to the extreme that'd be saying that JS engines should intentionally be slow in order to be "secure". JIT the code then inject a bunch of nop loops everywhere - you'd still be "preventing" meltdown, spectre, and rowhammer, but waste less power doing it.

JS engines are already intentionally slow. Look at all the hacks done to avoid random JS getting its hands on a precise timing source. Last time they straight up did away with SharedArrayBuffer.

This is all done to keep JIT around despite the obvious and massive security impact.

Re: JIT-Less V8

#84

Post by amaranth »

bodyfour wrote: post #67
schuay wrote: post #51

Earlier quoted context omitted.

> I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript. Theoretically yes, but this is not implemented. It should not be too hard to drastically reduce binary size with a build…

> It should not be too hard to drastically reduce binary size with a build-time flag. And then how portable would the code be? Would this be a path to running node on CPUs without JIT support? Or does it still have to mess with the calling convention at an assembly level?

According to another comment in this thread [1] the interpreter is actually generated by the JIT at compile time so no, this wouldn't let you run V8 on a CPU that isn't currently supported.

[1] https://news.ycombinator.com/item?id=19379305

Re: JIT-Less V8

#85

Post by abstractcontrol »

curtis wrote: post #55
mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

People were using Ruby and Python (and before that Perl and PHP) on the backend in many cases. I think it's likely that those are the kinds of projects which are using JS on the backend now, while the Java and C# people are continuing to do their backends in Java and C#. One of JavaScript's big advantages over Ruby and Python was performance, both because the standard runtime is faster (JITing JavaScript turned out t…

> JITing JavaScript turned out to be a lot easier than JITing Ruby and Python

Why was this the case?

Re: JIT-Less V8

#86

Post by c256 »

schuay wrote: post #48
xuejie wrote: post #46

Earlier quoted context omitted.

Thanks for the explanation! One follow-up question is: how can we still call ignition an interpreter with this flow where TurboFan is still used to generate machine code? Doesn't that defunct the idea of an interpreter in v8, which is to be used in platforms w/o write access to executable memory, such as iOS or PS4?

While bytecode handlers (and other builtins) are generated by TurboFan, this happens at V8-compile-time, not at runtime. Their generated code is shipped embedded into the binary as embedded builtins.

This suggests that a specialized app (such as a set-top box, smart TV, or game console) could push more code through the pre-JIT process to further close the performance gap. (This is interesting to me, because I haven’t seen much interest in pre-JIT compilation since the early days of Java, HotSpot, etc.)

Re: JIT-Less V8

#87

Post by MikeHolman »

cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

ChakraCore also has the ability to disable JIT. And we have a build configuration that compiles out the JIT so the binary is smaller as well.

I believe people in the community also have a ChakraCore fork specifically made for using Node on iOS.

Re: JIT-Less V8

#88

Post by MikeHolman »

hashseed wrote: post #70
gok wrote: post #62

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-cli…

V8 already employs W^X, i.e. memory pages allocated for V8's heap are either writable or executable, but not both at the same time.

By allowing JIT at all, a small ROP chain can call VirtualProtect to make a larger payload executable.

Sure you can do everything with ROP, but it is less convenient (and Intel CET might eventually make ROP attacks actually hard).

Re: JIT-Less V8

#89

Post by landr0id »

jayshua wrote: post #68
gok wrote: post #62

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-cli…

Anyone know how common attacks that take advantage of the JIT technology actually are?

It's been used consistently to get initial code execution on the PlayStation 4, iOS (for attacks involving just following a web link), and probably used pretty consistently other nation-state attacks but I have no real data to back this up.

The Pegasus spyware for instance utilized a JIT attack in JavaScriptCore in Safari for the initial stage.

Re: JIT-Less V8

#90

Post by danbolt »

As mentioned in the article, this is interesting for game developers that aren't allowed to run unsigned code (eg: JIT).

JavaScript is very popular the programming zietgiest and likely to be a language non-programmers are exposed to via the web. Part of me wonders if game engines would take to integrating it instead of Lua if designers might be more familiar with it.

Post reply on HN