V8 release v6.9

https://v8project.blogspot.com/2018/08/v8-release-69.html

by stablemap • 8 years ago

103 37 8 years ago

v8project.blogspot.com

Interested in those WebAssembly updates, hopefully someday Electron will see more WebAssembly usage (maybe mostly for games?) which should be interesting. I wonder if Kotlin will ever focus on running on WebAssembly.

Avamander• 8 years ago

I'm interested in seeing a whole new world of wasm exploits. I have a strong suspicion we're going to see the same types of bugs we're seeing with C and C++ in browsers which sounds a bit scary to be honest.

stcredzero• 8 years ago

It's also true that some huge fraction of Dalvik/Android exploits were based on the same sorts of optimizations which can be used to make wasm faster.

deweller• 8 years ago

I'm sure there will be exploits, as the attack surface will become bigger.

But isn't wasm designed from the ground up to be sandboxed in a certain memory space? And won't that prevent buffer overruns from gaining access to other parts of the browser?

rightbyte• 8 years ago

I got this feeling that the main selling point of wasm will be "certified" software with some middle man and control.

An analogy would be Google's push for https, for our own best ofc.

shawn• 8 years ago

Built-in functions currently consume 700 KB in each Isolate (an Isolate roughly corresponds to a browser tab in Chrome). This is quite wasteful, and last year we began working on reducing this overhead. In V8 v6.4, we shipped lazy deserialization, ensuring that each Isolate only pays for the built-ins that it actually needs (but each Isolate still had its own copy).

Also known as Autoload. What’s old is new again... http://www.gnu.org/software/emacs/manual/html_node/elisp/Aut...

Embedded built-ins go one step further. An embedded built-in is shared by all Isolates, and embedded into the binary itself instead of copied onto the JavaScript heap. This means that built-ins exist in memory only once regardless of how many Isolates are running, an especially useful property now that Site Isolation has been enabled by default.

Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs. Like, say, a timing attack on regex exec to reveal whether the word “Facebook” appears in some other tab. </baseless>

dividuum• 8 years ago

Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs.

Although I don't know all the internals of how chrome isolates tabs, I'm not sure how that's supposed to happen. If I understand the original approach correctly, it just means that the code is in the original binary, paged in once and using copy-on-write semantics while forking individual sandbox processes only exists as a single copy instead of multiple copies that would happen if the code somehow has to be prepared by "copying to the JS heap" of each individual sandbox process.

gsnedders• 8 years ago

Yes, this is my understanding of the implementation.

oscargrouch• 8 years ago

Is this even possible?

Its just read-only machine code, theres no stack data for instance from the last executions that you can watch for.

Maybe only if you know when the code is being executed, in which register that particular builtin write the memory address of the payload, and then go for the payload on the heap to see what's there.

To know when the code will be executed you would need to watch for the VM loop and to when that particular builtin you are interested in its on the 'execution needle'.. But to get there you would first need to find a exploit, with arbitrary code execution, where you can upload your exploit payload to hook on the VM loop (and this sounds a lot of work to me).

(Not a Sec. guy myself, so genuinely curious how this could be done, but trying to figure out a way to exploit this, i kind of begin to see how it could be done)

bovermyer• 8 years ago

This is the bit I'm most interested in:

WebAssembly got a new baseline compiler for much faster startup of complex websites with big WebAssembly modules (such as Google Earth and AutoCAD). Depending on the hardware we are seeing speedups of more than 10×. Stay tuned for more details in a separate blog post.

chacham15• 8 years ago

I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes sense to use right now is miniscule.

chinedufn• 8 years ago

Check out Rust’s wasm-bindgen - https://github.com/rustwasm/wasm-bindgen if ya haven’t already.

Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!

rudedogg• 8 years ago

Same, I started looking into WASM yesterday, and was disappointed to find out you can't do DOM manipulation as that was my use case.

From my brief research https://github.com/WebAssembly/host-bindings is the repository to watch for progress.

vardump5• 8 years ago

The possibility of WebAssembly becoming tangled with complicated web browsers worries me.

Whatever DOM manipulation there may be in the future, I hope there'll be no tight coupling with DOM, GC or anything else.

If tight coupling can be avoided, WebAssembly could become lingua franca of binary formats also outside web.

For things like architecture agnostic plugins, extensions and high performance light weight "scripting" support.

kuwze• 8 years ago

Why would you want to do that? DOM manipulation is what makes JS slow, not JS itself.

heydenberk• 8 years ago

nice

nojvek• 8 years ago

Love V8's focus on performance, security and memory usage. They really keep on pushing the bar.

V8 release v6.9

Related Stories