Skip to content

V
V8
Switch branch/tag
  1. 04 Apr, 2017 1 commit
  3. 01 Apr, 2017 1 commit
  5. 22 Mar, 2017 1 commit
  7. 21 Mar, 2017 2 commits
    • mtrofin's avatar
      Reland of [wasm] Transferrable modules (patchset #1 id:1 of... · 9dfa4639
      mtrofin authored 
      Reland of [wasm] Transferrable modules (patchset #1 id:1 of https://codereview.chromium.org/2762163002/ )

Reason for revert:
Temporarily disabled tests on chromium side (https://codereview.chromium.org/2764933002)

Original issue's description:
> Revert of [wasm] Transferrable modules (patchset #13 id:280001 of https://codereview.chromium.org/2748473004/ )
>
> Reason for revert:
> Breaks layout tests:
> https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312
>
> See https://github.com/v8/v8/wiki/Blink-layout-tests
>
> Original issue's description:
> > [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}
> > Committed: https://chromium.googlesource.com/v8/v8/+/99743ad460ea5b9795ba9d70a074e75d7362a3d1
>
> TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:6079
>
> Review-Url: https://codereview.chromium.org/2762163002
> Cr-Commit-Position: refs/heads/master@{#43981}
> Committed: https://chromium.googlesource.com/v8/v8/+/e538b70e1a45289dfe0fa9789563f023a5e9c22b

TBR=jbroman@chromium.org,bradnelson@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6079

Review-Url: https://codereview.chromium.org/2762273002
Cr-Commit-Position: refs/heads/master@{#43994}
      9dfa4639
    • machenbach's avatar
      Revert of [wasm] Transferrable modules (patchset #13 id:280001 of... · e538b70e
      machenbach authored 
      Revert of [wasm] Transferrable modules (patchset #13 id:280001 of https://codereview.chromium.org/2748473004/ )

Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312

See https://github.com/v8/v8/wiki/Blink-layout-tests

Original issue's description:
> [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}
> Committed: https://chromium.googlesource.com/v8/v8/+/99743ad460ea5b9795ba9d70a074e75d7362a3d1

TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6079

Review-Url: https://codereview.chromium.org/2762163002
Cr-Commit-Position: refs/heads/master@{#43981}
      e538b70e
  9. 20 Mar, 2017 1 commit
    • 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
  11. 17 Mar, 2017 2 commits
  13. 28 Feb, 2017 1 commit
    • jbroman's avatar
      ValueSerializer: Add an explicit tag for host objects. · 65435199
      jbroman authored 
      This makes it no longer necessary to ensure that V8 and Blink have non-colliding
tags, which makes it easier for them to evolve independently, and also makes
the wire format more suitable for other V8 embedders, who would not
necessarily be surveyed before V8 introduced a new tag that might collide
with theirs.

BUG=chromium:686159

Review-Url: https://codereview.chromium.org/2709023003
Cr-Commit-Position: refs/heads/master@{#43466}
      65435199
  15. 23 Feb, 2017 1 commit
    • jbroman's avatar
      ValueDeserializer: Make sure that an exception is the legacy path. · 68960eeb
      jbroman authored 
      The entry points to the deserializer are responsible for ensuring that an
exception is pending by the time they return. Some failures throw exceptions
themselves, while others (like errors in the format) are exceptions caused by
the deserializer, not coming from the runtime.

Like the non-legacy path, a default deserialization exception should be thrown
in such cases.

BUG=chromium:693411

Review-Url: https://codereview.chromium.org/2712713002
Cr-Commit-Position: refs/heads/master@{#43390}
      68960eeb
  17. 22 Feb, 2017 1 commit
  19. 20 Feb, 2017 1 commit
  21. 17 Feb, 2017 1 commit
  23. 16 Feb, 2017 1 commit
    • jbroman's avatar
      ValueDeserializer: Only allow valid keys when deserializing object properties. · 8990399d
      jbroman authored 
      The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).

This case is now rejected by the deserializer.

BUG=chromium:686511

Review-Url: https://codereview.chromium.org/2697023002
Cr-Commit-Position: refs/heads/master@{#43249}
      8990399d
  25. 10 Feb, 2017 1 commit
  27. 04 Feb, 2017 1 commit
  29. 01 Feb, 2017 2 commits
  31. 31 Jan, 2017 1 commit
  33. 30 Jan, 2017 2 commits
  35. 28 Jan, 2017 1 commit
    • jbroman's avatar
      ValueSerializer: Support efficiently reading and writing one-byte strings. · bf511b42
      jbroman authored 
      memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
serializing and deserializing long ASCII strings, according to
blink_perf.bindings -- and these are already in a fast path where the entire
string is known to be ASCII (but this has to be checked). The win may be
larger for strings in Latin-1 but not ASCII (though I suspect this is an
uncommon case).

A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
survive wire format version number changes.

This is the first of a series of wire format changes from the previous Blink
format. The deserializer continues to be able to read the old format, but
Chromium M56 will no longer be able to read the messages written by this, in M58.

BUG=chromium:686159

Review-Url: https://codereview.chromium.org/2658793004
Cr-Commit-Position: refs/heads/master@{#42753}
      bf511b42
  37. 27 Jan, 2017 1 commit
  39. 26 Jan, 2017 1 commit
    • jbroman's avatar
      ValueSerializer: Promote scheduled exceptions from wasm::ErrorThrower. · 78c0be52
      jbroman authored 
      wasm::ErrorThrower doesn't actually throw exceptions, it just schedules them.
As a result, this exception isn't handled properly by code which expects
ValueDeserializer to actually throw. For instance, the unit tests use a
TryCatch to catch and handle expected exceptions in unit tests.

Before this patch, I see local unit test failures because a wasm decode test
schedules one, but it isn't caught (and instead causes Context::New to fail
at the beginning of the next test).

BUG=685713

Review-Url: https://codereview.chromium.org/2659483004
Cr-Commit-Position: refs/heads/master@{#42718}
      78c0be52
  41. 20 Jan, 2017 1 commit
  43. 19 Jan, 2017 2 commits
  45. 16 Jan, 2017 1 commit
  47. 13 Jan, 2017 3 commits
  49. 12 Jan, 2017 2 commits
  51. 11 Jan, 2017 2 commits
  53. 10 Jan, 2017 4 commits
  55. 03 Jan, 2017 1 commit