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

91–100 of 117 posts

Re: JIT-Less V8

#91

Post by kllrnohj »

gok wrote: post #82
kllrnohj wrote: post #78

Earlier quoted context omitted.

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

Which didn't need RWX by using ROP chains instead...?

The security vulnerability there was that the process had the ability to invoke shell at all, not how they got to invoking shell. In-process sandboxing isn't a thing anymore, spectre proved that. In that context what risk does RWX actually pose?

Re: JIT-Less V8

#92

Post by writepub »

THIS is another reason to complain to EU regulators [1], regarding Apple's unfair trade practices. Never before in the history of computing, has a company so blatantly suppressed the competition and gotten away with murder. V8 should not be the one needing re-architecture to meet anti-competitive iOS App Store rules, the rules need to make common sense, and treat the competition fairly.

[1]: https://techcrunch.com/2019/03/13/spotify-files-a-complaint-...

Re: JIT-Less V8

#93

Post by cromwellian »

sharpercoder wrote: post #58
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…

But is the increasing complexity (an interpreter added to the codebase) not introducing also another - new - attack vector?

IMHO, interpreters are simpler and easier to understand than optimizing JITs. Just look at the recent V8 range-check elimination bug around WASM optimizing +0 and -0 differently in a Math related intrinsic.

Re: JIT-Less V8

#94

Post by curtis »

abstractcontrol wrote: post #85
curtis wrote: post #55

Earlier quoted context omitted.

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?

I suspect that a lot of the impediment to JITing Ruby and Python effectively was due to large and important libraries (standard and third-party) being written in C using interfaces that were not JIT-friendly. JavaScript in the browser also depends on C/C++ interfaces to important functionality, but the entire stack for each engine was controlled by a single organization, and was always released as a unit (the web browser). I think this largely eliminated library inertia (or whatever you want to call it) as a problem when replacing a JavaScript engine.

The other advantage JavaScript had was that there were large, well-funded organizations (notably Google and Mozilla) competing on performance. Python and Ruby were always community projects and they had a strong emphasis on maintaining backwards compatibility with a large and diverse ecosystem, and there wasn't a lot of demand for faster implementations.

Re: JIT-Less V8

#95

Post by xsmasher »

childintime wrote: post #63

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

The "without allocating executable memory at runtime" means "without using allocating pages that are marked as executable," not "without allocating memory."

Re: JIT-Less V8

#96

Post by tuxxy »

Wow, this is pretty neat.

We might be able to finally run more safe cryptography in the browser with constant-time guarantees (there are other concerns with browser-based crypto though).

Re: JIT-Less V8

#97

Post by ptx »

childintime wrote: post #63

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

Java did use an interpreter - it didn't get a JIT compiler until version 1.2. Java is slow for many other reasons as well.

Re: JIT-Less V8

#98

Post by olliej »

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?

the RWX memory in JSC has frequently been used as the start of full remote code execution, but has become progressively harder to abuse over the years (via W^X and in newer hardware PAC).

Re: JIT-Less V8

#99

Post by DonHopkins »

0815test wrote: post #18
est31 wrote: post #15

Earlier quoted context omitted.

There's a software-level rule that forbids JIT engines by never allowing apps to mark pages as executable. According to this rule, you could run Chrome on iOS now. But there's also a policy level rule: > 4.7 HTML5 Games, Bots, etc. > Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as [...] the software [...] only uses capabilities available in a standard W…

You could use the XCode linker to embed your JS/WASM code in the binary as a read-only resource/section, and then run it using JIT-less V8. Interpreted code is generally more compact than a native ISA like ARM64, so this could be useful in order to reduce app size.

That's a lot like what Unity3D used to do with Mono CLR byte code on iOS. But now it uses IL2CPP to compile it into C++.

Re: JIT-Less V8

#100

Post by olliej »

bastawhiz wrote: post #49

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. I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), b…

In JSC it's guarded by compile time, runtime, and iOS OS enforcement.
Post reply on HN