> 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.
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.
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!
It isn’t clear how they will allow safe access to the DOM without GC. Maybe they’ll take an approach like Microsoft did with UWP and use reference counting?
Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...
I think the point is to integrate WebAssembly with JavaScript objects in general, not the DOM API in particular. Nothing to do with web browsers, everything to do with JavaScript.
It's called the "host bindings" proposal because the proposal is to create bindings to the host environemnt; for a browser that's the DOM, for for any other host, it could be other things. It's not tightly coupled to them.
Everyone[1] who works on wasm cares about the non-browser use-case, so I think you can sleep easy here.
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".
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.
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.
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?
Yes it is sanboxed, but the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.
> the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.
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.
WebAssembly does have bounds checking, you can't write outside the designated memory block.
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.
The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
Funny question, basically with corrupted data anything goes.
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.
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.
WebAssembly works pretty much like Javascript: it doesn't have any new platform APIs, browsers can execute it without special permissions, it can be retrieved from a web server, etc. Any planned lockdown of it would be just as easy to do with javascript.
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).
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>
> 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.
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)
I love WebAssembly and I don't agree with GP at all here, but this prevailing holier-than-thou attitude of "You shouldn't complain or poke holes in things unless you're willing to fix them yourself" is just silly, so I down-voted you.
Trying to poke holes in things, or raising concerns about them, is contributing. I would rather hear other people's arguments (even if I don't agree with them) than silence them on the grounds of "let's see you do better n00b".
Could we please drop this "if you see a problem just contribute" and switch to "if you can contribute then please do"?
I have a feeling that this is a common way in the OSS community to dismiss suggestions, ideas and criticism instead of taking them into account, feel free to correct me if this isn't the case.
EDIT: Seems I'm not the only one that's annoyed by this.
They’ll have to wait in line. My time is far too valuable to give it away. I have tremendous things to accomplish.
Actually, I would be surprised if a vuln creeps its way into a builtin. Most of the runtime should be stateless, and regex exec was the only one I could think of that might do some fancy memoization. But I hear it’s fun to collect a paycheck at pwn2own.
> 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.