• mtrofin's avatar
    [wasm] Transferrable modules · 99743ad4
    mtrofin authored
    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}
    99743ad4
v8.h 317 KB