V8 release v6.9
v8project.blogspot.com
v8project.blogspot.com
> 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.
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!
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.
Hopefully it'll stay that way.
Dependencies on DOM or Javascript would be devastating for WebAssembly use outside web browsers.
1: Okay so, what I really mean is, "I spend a lot of time talking to people working on WebAssembly and they've all expressed that to me but of course I hvaen't talked to literally every single last person".
From my brief research https://github.com/WebAssembly/host-bindings is the repository to watch for progress.
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?
it can be, but there are large classes of security issues that aren't possible like they usually are with those languages. eg it's not possible to jump to arbitrary locations, you can't write to executable memory, etc.
On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region.
If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter.
Performance and security win.
Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
You can't overwrite code or the true call stack, so what's the (security) risk?
For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor.
But yeah, code and true call stack will be perfectly safe.
It's just a matter of time.
* Or any other device with data corrupting hardware or software issues.
Successful lawsuits against insecure software need to become a common event until most companies actually start paying attention to their technology stack and development processes.
The goal of software security is to minimize all attack vectors.
Logic bugs < Logic bugs + Memory corruption bugs
An analogy would be Google's push for https, for our own best ofc.
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>
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.
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)