Skip to content

V
V8
Switch branch/tag
  1. 19 Jun, 2018 1 commit
  3. 11 Jun, 2018 1 commit
  5. 02 May, 2018 1 commit
  7. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored 
      The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.

With that in place, we also remove the array masking approach based
on arithmetic.

Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.

Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.

Bug: chromium:798964

Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  9. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored 
      This CL changes the poisoning in the interpreter to use the
infrastructure used in the JIT.

This does not change the original flag semantics:

--branch-load-poisoning enables JIT mitigations as before.

--untrusted-code-mitigation enables the interpreter mitigations
  (now realized using the compiler back-end), but does not enable
  the back-end based mitigations for the Javascript JIT. So in effect
  --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
  use the same mechanics (including changed register allocation) that
  --branch-load-poisoning enables for the JIT.

Bug: chromium:798964
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  11. 21 Mar, 2018 1 commit
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, mips & mips64) · 1177f703
      Mike Stanton authored 
      This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only under the
--branch-load-poisoning flag, and this CL enlarges the set of supported
platforms from {x64, arm, arm64} to {x64, arm, arm64, mips, mips64}.

Overview of changes:
- new register configuration configuration with one register reserved for
  the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
  of all successors of branches (and deopts) that are marked as safety
  branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
  (In this CL, this last step is left as a TODO. You can run with the flag,
   though mitigations will just not be effective at this time).
  * only integer loads are masked at the moment.

TBR=mstarzinger@chromium.org

Change-Id: Ie6eb8719bf85d49c03b4a28e2f054480195a1471
Reviewed-on: https://chromium-review.googlesource.com/973616
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52123}
      1177f703
  13. 19 Mar, 2018 2 commits
    • Michael Stanton's avatar
      Revert "[turbofan] Masking/poisoning in codegen (optimized code, mips & mips64)" · 11831378
      Michael Stanton authored 
      This reverts commit 46a3c772.

Reason for revert: This is actually not quite ready. What we need is a speculation free poisoning, and if we do another branch, then I think that won't happen.

Original change's description:
> [turbofan] Masking/poisoning in codegen (optimized code, mips & mips64)
> 
> This introduces masking of loads with speculation bit during code generation.
> At the moment, this is done only under the
> --branch-load-poisoning flag, and this CL enlarges the set of supported
> platforms from {x64, arm, arm64} to {x64, arm, arm64, mips, mips64}.
> 
> Overview of changes:
> - new register configuration configuration with one register reserved for
>   the speculation poison/mask (kSpeculationPoisonRegister).
> - in codegen, we introduce an update to the poison register at the starts
>   of all successors of branches (and deopts) that are marked as safety
>   branches (deopts).
> - in memory optimizer, we lower all field and element loads to PoisonedLoads.
> - poisoned loads are then masked in codegen with the poison register.
>   * only integer loads are masked at the moment.
> 
> Bug: chromium:798964
> Change-Id: I211395b8305ed0ad9288d6da48fa159fa970c827
> Reviewed-on: https://chromium-review.googlesource.com/951382
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
> Cr-Commit-Position: refs/heads/master@{#52042}

TBR=mvstanton@chromium.org,mstarzinger@chromium.org,ivica.bogosavljevic@mips.com

Change-Id: Ief4d9ef56d918172f0b545d321a64b1ab5b46915
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:798964
Reviewed-on: https://chromium-review.googlesource.com/969041Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52045}
      11831378
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, mips & mips64) · 46a3c772
      Mike Stanton authored 
      This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only under the
--branch-load-poisoning flag, and this CL enlarges the set of supported
platforms from {x64, arm, arm64} to {x64, arm, arm64, mips, mips64}.

Overview of changes:
- new register configuration configuration with one register reserved for
  the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
  of all successors of branches (and deopts) that are marked as safety
  branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
  * only integer loads are masked at the moment.

Bug: chromium:798964
Change-Id: I211395b8305ed0ad9288d6da48fa159fa970c827
Reviewed-on: https://chromium-review.googlesource.com/951382Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIvica Bogosavljevic <ivica.bogosavljevic@mips.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#52042}
      46a3c772
  15. 09 Mar, 2018 1 commit
  17. 08 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] [cleanup] remove UnalignedLoadRepresentation · 501f250c
      Tobias Tebbi authored 
      UnalignedLoad is the only kind of load operation that defines its own
UnalignedLoadRepresentation type alias and LoadRepresentationOf function.
This is a problem because it means we cannot use the LOAD_MATCHER
infrastructure without defining all of this boilerplate for all the other
kinds of load operations. Since these aliases serve no real purpose,
it is best to unify UnalignedLoad to how its peers are handled.

Change-Id: I51a591eb82fb85edee66512136b23276e851f767
Reviewed-on: https://chromium-review.googlesource.com/951683
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51802}
      501f250c
  19. 05 Mar, 2018 2 commits
  21. 02 Mar, 2018 3 commits
  23. 23 Feb, 2018 1 commit
  25. 21 Feb, 2018 1 commit
  27. 20 Feb, 2018 1 commit
  29. 13 Feb, 2018 1 commit
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, x64) · 8f489e73
      Mike Stanton authored 
      This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only for x64 optimized code, under the
--branch-load-poisoning flag.

Overview of changes:
- new register configuration configuration with one register reserved for
  the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
  of all successors of branches (and deopts) that are marked as safety
  branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
  * only integer loads are masked at the moment.

Bug: chromium:798964
Change-Id: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
Reviewed-on: https://chromium-review.googlesource.com/901625
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51272}
      8f489e73
  31. 09 Feb, 2018 1 commit
  33. 08 Feb, 2018 1 commit
  35. 07 Feb, 2018 1 commit
    • Predrag Rudic's avatar
      MIPS[64] Port:"[cctest] Support testing Simd128 moves and swaps" · 7352b3f8
      Predrag Rudic authored 
      Port 0761b55d

Original Commit Message:

"Extend the code-generator tests to cover AssembleMove and AssembleSwap with
Simd128 registers and stack slots, for targets that support them.

For this to work however, we need support for passing Simd128 stack parameters
in TurboFan which this patch implements for Arm and x86. PPC and S390 both do
not support the Simd128 representation and it appears MIPS and MIPS64's
implementation of AssembleMove and AssembleSwap do not support it either.

As per the design of the tests, the set of values to perform moves on are
represented in a FixedArray of Smis (for kTagged) and HeapNumbers (for kFloat32
and kFloat64). They are converted to raw values for the moves to be performed
on, to be then converted back into a FixedArray. For the kSimd128
representation, we represent values as a FixedArray of 4 Smis, each representing
a lane. They are converted to a raw Simd128 vector using the `I32x4ReplaceLane`
and `I32x4ExtractLane` operations.

Finally, these tests need Simd128 variables mixed with the CodeStubAssembler
which is not a use-case officially supported. And as a result, the `RecordWrite`
stub does not guarantee to preserve Simd128 registers. To get around this, we
have to be careful to skip write barriers when dealing with Simd128 parameters
inside the "teardown" function, and we've had to move all allocations to the
"setup" function.

Thanks to this, we are able to catch bugs such as this one
https://bugs.chromium.org/p/v8/issues/detail?id=6843."

Change-Id: If867dedf4a2c72cb75c58effda93e3eec432fd67
Reviewed-on: https://chromium-review.googlesource.com/906469Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#51142}
      7352b3f8
  37. 01 Feb, 2018 1 commit
  39. 31 Jan, 2018 2 commits
  41. 26 Jan, 2018 1 commit
  43. 25 Jan, 2018 1 commit
  45. 19 Jan, 2018 1 commit
  47. 15 Jan, 2018 1 commit
  49. 04 Jan, 2018 1 commit
  51. 02 Jan, 2018 1 commit
  53. 22 Dec, 2017 1 commit
    • Andreas Haas's avatar
      [mips64][turbofan] Implement on-stack returns. · 461274fb
      Andreas Haas authored 
      This is the implementation of crrev.com/c/766371 for mips64.

Original description:

Add the ability to return (multiple) return values on the stack:

- Extend stack frames with a new buffer region for return slots.
  This region is located at the end of a caller's frame such that
  its slots can be indexed as caller frame slots in a callee
  (located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
  reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.

R=v8-mips-ports@googlegroups.com

Change-Id: Ia924f94367320b9062e33d35b58ccd38c8fc3ca3
Reviewed-on: https://chromium-review.googlesource.com/842483Reviewed-by: 's avatarIvica Bogosavljevic <ivica.bogosavljevic@mips.com>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50299}
      461274fb
  55. 13 Dec, 2017 1 commit
  57. 12 Dec, 2017 2 commits
    • Ben L. Titzer's avatar
      [turbofan] Remove CheckedStore from TurboFan backend. · 65ac8ca0
      Ben L. Titzer authored 
      This operation was used to implement asm.js stores, but is obsolete
with asm.js stores now being lowered to normal graph nodes.

R=mstarzinger@chromium.org
CC=jarin@chromium.org

Bug: 
Change-Id: Iea90b1a62be2e273c0562058642adc5b63ae2cf8
Reviewed-on: https://chromium-review.googlesource.com/822570
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50046}
      65ac8ca0
    • Andreas Haas's avatar
      Reland [turbofan] Implement on-stack returns (Intel) · bd732f7d
      Andreas Haas authored 
      The original CL introduced a test which uses a random number generator.
I disable the test for now, which is okay because this CL adds to a
work-in-progress feature anyways, and I will fix the problem in another
CL.

Original description:
Add the ability to return (multiple) return values on the stack:

- Extend stack frames with a new buffer region for return slots.
  This region is located at the end of a caller's frame such that
  its slots can be indexed as caller frame slots in a callee
  (located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
  reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.

So far, only ia32 and x64 are implemented.

Change-Id: I8b03fc4e53946daaa0e14a34603f4824a04fad7e
Reviewed-on: https://chromium-review.googlesource.com/819557Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50031}
      bd732f7d
  59. 11 Dec, 2017 2 commits
    • Andreas Haas's avatar
      Revert "[turbofan] Implement on-stack returns (Intel)" · 943ccb98
      Andreas Haas authored 
      This reverts commit 1e49864f.

Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0

Original change's description:
> [turbofan] Implement on-stack returns (Intel)
> 
> Add the ability to return (multiple) return values on the stack:
> 
> - Extend stack frames with a new buffer region for return slots.
>   This region is located at the end of a caller's frame such that
>   its slots can be indexed as caller frame slots in a callee
>   (located beyond its parameters) and assigned return values.
> - Adjust stack frame constructon and deconstruction accordingly.
> - Extend linkage computation to support register plus stack returns.
> - Reserve return slots in caller frame when respective calls occur.
> - Introduce and generate architecture instructions ('peek') for
>   reading back results from return slots in the caller.
> - Aggressive tests.
> - Some minor clean-up.
> 
> So far, only ia32 and x64 are implemented.
> 
> Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
> Reviewed-on: https://chromium-review.googlesource.com/766371
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49994}

TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org

Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/819637Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50000}
      943ccb98
    • Andreas Haas's avatar
      [turbofan] Implement on-stack returns (Intel) · 1e49864f
      Andreas Haas authored 
      Add the ability to return (multiple) return values on the stack:

- Extend stack frames with a new buffer region for return slots.
  This region is located at the end of a caller's frame such that
  its slots can be indexed as caller frame slots in a callee
  (located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
  reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.

So far, only ia32 and x64 are implemented.

Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
Reviewed-on: https://chromium-review.googlesource.com/766371
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49994}
      1e49864f
  61. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored 
      This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.

Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.

Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters

Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.

BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  63. 01 Dec, 2017 1 commit
  65. 18 Oct, 2017 1 commit