commit 99743ad460ea5b9795ba9d70a074e75d7362a3d1
author mtrofin <mtrofin@chromium.org> Mon Mar 20 19:03:23 2017
committer Commit bot <commit-bot@chromium.org> Mon Mar 20 19:03:23 2017
tree 0e1939027a2b7e83980fec2fb19c2997d865b3eb
parent b1841eecb4d603e2f98f9464b4bef9d32b6e140b

[wasm] Transferrable modules

We want to restrict structured cloning in Chrome to:
- postMessage senders and receivers that are co-located
in the same process
- indexedDB (just https).

For context, on the Chrome side, we will achieve the postMessage part
by using a mechanism similar to transferrables: the
SerializedScriptValue will have a list of wasm modules, separate from
the serialized data stream; and this list won't be copied cross
process boundaries. The IDB part is achieved by explicitly opting in
reading/writing to the serialization stream. To block attack vectors
in IPC cases, the default for deserialization will be to expect data
in the wasm transfers list.

This change is the V8 side necessary to enabling this design. We
introduce TransferrableModule, an opaque datatype exposed to the
embedder. Internally, TransferrableModules are just serialized data,
because we don't have a better mechanism, at the moment, for
de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
Context).

The chrome defaults will be implemented in the
serialization/deserialization delegates on that side. For the v8 side
of things, in the absence of a serialization delegate, the V8
serializer will write to serialization stream. In the absence of a
deserialization delegate, the deserializer won't work. This asymmetry
is intentional - it communicates to the embedder the need to make a
policy decision, otherwise wasm serialization/deserialization won't
work "out of the box".

BUG=v8:6079

Review-Url: https://codereview.chromium.org/2748473004
Cr-Commit-Position: refs/heads/master@{#43955}