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

71–80 of 117 posts

Re: JIT-Less V8

#71

Post by gok »

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.

Well, except for WebAssembly. But even then, it's still fundamentally possible to hijack control of whatever changes the pages from RW to RX.

Re: JIT-Less V8

#72

Post by munificent »

spacenick88 wrote: post #59
sharpercoder wrote: post #58

Earlier quoted context omitted.

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

The interpreter has always been part of the codebase since it is used during startup and while the code is still being JITed

Not always, actually. V8 came out in 2008 and didn't have an interpreter until 2016. For the first eight years, the non-optimization execution was also a JIT, just a simpler one.

Re: JIT-Less V8

#73

Post by simias »

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…

I don't like JS very much so I wouldn't want to use it anywhere it could be avoided, that being said it's pretty clear why some people think otherwise, regardless of the qualities and defects of the language.

Using JS in the backend means that you don't have to learn a new language if you're already familiar with it in the browser. Given that webdev is extremely popular with new developers these days, it's not surprising that they might want to reuse the technology when they have to write backend code instead of learning a whole new language. Similarly companies can reuse their pools of webdevs to write non-web applications instead of hiring new personnel or having to retrain the existing coders.

It also means that you can reuse code from the browser in the backend.

Sure if you find JS a clunky and subpar language it might be disappointing to see it spread the way it does but hey, at least it's not PHP!

Re: JIT-Less V8

#74

Post by hajile »

What about Proper Tail Calls?

Duktape and XS support them. JSC has had them for years now too. That's a big feature to accidentally miss. You switch and then inadvertently blow your stack every now and then because v8 decided to remove their already implemented tail calls for no good reason (Lest we go down the road again, the "alternative syntax" proposal was dropped, so there's zero excuses aside from a deliberate violation of the spec).

Re: JIT-Less V8

#75

Post by piannucci »

How bad of an idea would it be to create a ROP-based JIT engine for these platforms? You could hand-craft the gadgets and use the stack to reduce interpreter dispatch overhead.

Re: JIT-Less V8

#76

Post by Scaevolus »

piannucci wrote: post #75

How bad of an idea would it be to create a ROP-based JIT engine for these platforms? You could hand-craft the gadgets and use the stack to reduce interpreter dispatch overhead.

That's called "Subroutine threading"! :-) https://en.wikipedia.org/wiki/Threaded_code#Subroutine_threa...

V8's Ignition interpreter is implemented with "Direct threading", which is quite similar but (probably?) faster on modern processors-- it does an indirect jump to the next bytecode handler instead of a return: https://news.ycombinator.com/item?id=10034167

"The bytecode handlers are not intended to be called directly, instead each bytecode handler dispatches to the next bytecode. Bytecode dispatch is implemented as a tail call operation in TurboFan. The interpreter loads the next bytecode, indexes into the dispatch table to get the code object of the target bytecode handler, and then tail calls the code object to dispatch to the next bytecode handler."

Re: JIT-Less V8

#77

Post by mark-r »

mark-r wrote: post #40

Just another indication of Google trying to take over the world. There's a class of machines where Chrome can't run? We need to fix that, stat!

The tone may be flippant, but I was serious. Google's M.O. is to expand their reach into as many corners of our lives as possible. Having devices that can't run Javascript on Chrome is an impediment to that goal, and so I'm sure the marching orders were to find a way to make it work. It is already acknowledged that some upcoming work will be done to improve areas that are still too slow.

Re: JIT-Less V8

#78

Post by kllrnohj »

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.

Re: JIT-Less V8

#79

Post by xsmasher »

0815test wrote: post #27
saagarjha wrote: post #25

Earlier quoted context omitted.

> 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. Or just read it from a file?

It needs to be embedded in the binary, because code that is not so embedded has different rules applied to it. So, it has to be done either in the compiler (e.g. as compile-time const arrays, which will then be part of the rodata section) or in the linker; the latter is arguably a bit easier.

"The binary" in this context means the ipa (archive) that you send to Apple.

They are making a distinction between downloaded data and data included in the archive, but using sloppy terminology.

Re: JIT-Less V8

#80

Post by kllrnohj »

stefan_ wrote: post #26
bjourne wrote: post #20

I'm skeptical of the claim of improved security. Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit.

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.
Post reply on HN