Intent to implement Structured Cloning for WebAssembly Compiled Modules

[Mircea Trofin]

Contact emails

mtr...@chromium.org

Summary

WebAssembly modules may contain large bodies of code, such as a game. Compiling such a module may be time consuming. A stepping stone towards improving the resulting user experience is enabling structured cloning for compiled WebAssembly modules, which would allow them to be stored in IndexedDB, or compiled by a Worker (these are just examples). The feature is further described in the WebAssembly public design document here (Note that the WebAssembly specification is still in flux)

In Chrome, the feature is enabled through changes to the structured cloning code (ScriptValueSerializer, mainly). Seehttps://codereview.chromium.org/2255673003/, the first CL.

Ongoing technical constraints

None

Tracking bug

Tracked by v8 issue https://bugs.chromium.org/p/v8/issues/detail?id=5072

[Jochen Eisinger]

+blink-dev as this is webexposed behavior.

Since we also allow for sending serialized script values between origins and even processes, I'd propose to first restrict this to same origin, and just refuse to deserialize wasm binaries from different origins

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Elliott Sprehn]

+jbroman

[Jeremy Roman]

I've already talked a little with Mircea; I expect we'll be able to deal with ScriptValueSerializer being replaced without much trouble.

I've previously mentioned what happens when an unsupported (or, as Jochen points out, untrusted) module is seen by the deserializer. The linked doc seems to say that it should still work (which seems to imply sending both the compiled _and_ uncompiled module), though I've heard producing null in certain as an alternative.

(As far as the cross-origin policy goes, I think this can be detected at serialization time, which seems better to me because we have the opportunity to throw a useful DataCloneError then.)

[Jochen Eisinger]

If we assume a compromised renderer, the check at serialization time doesn't help much

[Jeremy Roman]

On Fri, Sep 2, 2016 at 1:39 PM, Jochen Eisinger <joc...@chromium.org> wrote:

If we assume a compromised renderer, the check at serialization time doesn't help much

Agreed that the sending renderer cannot be trusted. It just helps an author who makes the mistake innocently figure out what went wrong.

[Elliott Sprehn]

Why do we think sending WebAssembly is scarier than sending JS source text?

[Jeremy Roman]

On Fri, Sep 2, 2016 at 1:48 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Why do we think sending WebAssembly is scarier than sending JS source text?

This proposal would send the compiled V8 representation, rather than the format sent over the network. (The objective being to avoid the time spent compiling.)

[Elliott Sprehn]

On Fri, Sep 2, 2016 at 10:50 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Fri, Sep 2, 2016 at 1:48 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Why do we think sending WebAssembly is scarier than sending JS source text?

This proposal would send the compiled V8 representation, rather than the format sent over the network. (The objective being to avoid the time spent compiling.)

Right, I'm asking why jochen would want us to restrict this to same origins. :)

[Jochen Eisinger]

We can't verify that it's actually compiled wasm. It's essentially an API that allows for sending an arbitrary binary to another process which we'll then helpfully map into executable memory.

By restricting this to same origin, and once oopif is on by default, we'd make this exploit less likely (compromising one renderer from another)

[Ian]

I might be missing something here... isn't WebAssembly.Module just a opaque handle to the compiled binary? (which it seems by reading the reading the API can only come from the output of compiling an AST? i.e. we have full control as to what is in the binary?)

How are we unable to verify that it's compiled wasm if that is the case?

(again, sorry, i might be missing something obvious).

Ian

[Ryan Sleevi]

On Fri, Sep 2, 2016 at 2:12 PM, Ian <ikilp...@chromium.org> wrote:

I might be missing something here... isn't WebAssembly.Module just a opaque handle to the compiled binary? (which it seems by reading the reading the API can only come from the output of compiling an AST? i.e. we have full control as to what is in the binary?)

If a single renderer does the compilation, then it can know that its' Module was compiled by it.

However, if it needs to send to another renderer, how does the receiving renderer know that the source renderer truly compiled it, as opposed to, say, was compromised and is doing Something Evil(tm)

 

The issue is that renderers mutually distrust eachother (mod a bunch of handwaving), so if a Module needs to cross renderer boundaries (e.g. cross-origin), it becomes harder to know whether it's trustworthy.

You'd have to setup a trusted third-party (e.g. a "WASM module compiler process") if you wanted to pass handles with trust - since you know X is trustworthy if X can only come from a trusted source.

Gross oversimplification, but that may highlight the concern :)

[Mircea]

(apologies to those receiving this twice)

Resurrecting this.

For the cross-origin scenario, what if sending cross-origin required recompiling on the other side? Or do we currently block sending any scripts cross-origin.

[Mircea Trofin]

FWIW - https://github.com/WebAssembly/design/issues/956