1. 16 Jun, 2020 2 commits
  2. 09 Jun, 2020 1 commit
  3. 17 Mar, 2020 1 commit
  4. 24 Feb, 2020 1 commit
  5. 19 Feb, 2020 1 commit
  6. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored
      This is a reland of 137bfe47
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      Bug: v8:10026
      Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  7. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored
      This reverts commit 137bfe47.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored
      This change uses the Arm v8.3 pointer authentication instructions in
      order to protect return addresses stored on the stack.  The generated
      code signs the return address before storing on the stack and
      authenticates it after loading it. This also changes the stack frame
      iterator in order to authenticate stored return addresses and re-sign
      them when needed, as well as the deoptimizer in order to sign saved
      return addresses when creating new frames. This offers a level of
      protection against ROP attacks.
      
      This functionality is enabled with the v8_control_flow_integrity flag
      that this CL introduces.
      
      The code size effect of this change is small for Octane (up to 2% in
      some cases but mostly much lower) and negligible for larger benchmarks,
      however code size measurements are rather noisy. The performance impact
      on current cores (where the instructions are NOPs) is single digit,
      around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      cores than for little cores.
      
      Bug: v8:10026
      Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  8. 03 Feb, 2020 1 commit
  9. 14 Nov, 2019 2 commits
  10. 04 Sep, 2019 1 commit
  11. 03 Sep, 2019 1 commit
    • Pierre Langlois's avatar
      [arm64] Fix backwards branch ranges. · ffffed90
      Pierre Langlois authored
      The `Instruction::IsValidImmPCOffset()` method was taking an `offset` argument
      in numbers of *instructions* while we were passing it numbers of *bytes*. See
      `Instruction::IsTargetInImmPCOffsetRange()` and
      `MacroAssembler::NeedExtraInstructionsOrRegisterBranch()`.
      
      As a result, we were 4 times too conservative when computing branch ranges going
      backwards, forcing us to generate the following sequence for TBZ more often than
      needed:
      
      ```
        TBNZ <skip>
        B <target>
      skip:
      ```
      
      This happened rarely for loops, but a lot when doing an early return from
      out-of-line calls to write barriers. Since out-of-line code is easily out of
      range of 8K, although the real range of TBZ is 32K.
      
      This fixes it by changing this method to take a byte offset instead of
      instructions, as this is more intuitive and in line with similar methods. For
      instance, `Instruction::ImmPcOffset()` returns an offset in bytes.
      
      The tests are adapted so that they would have caught such a bug:
      
      * TEST(far_branch_backward):
      
        This test used to only check the code worked if the branch was very far away,
        but it didn't test the range was correct. So this test was changed to check
        each branch type separately, and test in-range and out-of-range cases
        separately too.
      
      * TEST(far_branch_veneer_broken_link_chain):
      
        Because of the backwards range bug, this test wasn't actually testing what it
        should. The idea of the test is to make sure the MacroAssembler can still cope
        when the chain of links is broken after a veneer was emitted. But no veneers
        were ever emitted.
      
      Change-Id: Iddb5c683a71147455175f38fa7ae57da0a3e7337
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781058Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63518}
      ffffed90
  12. 24 Jul, 2019 1 commit
  13. 18 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      Reland "[arm64] Refactor constant pool implementation" · e93d244f
      Sigurd Schneider authored
      This is a reland of ac79b539
      
      This CL adds a missing BlockPoolsScope to guard a RequestHeapObject
      call. This fixes a latend bug that the original land flushed out.
      
      Original change's description:
      > [arm64] Refactor constant pool implementation
      >
      > This refactors the constant pool handling for arm64. The immediate goal
      > is to allow 32bit compressed pointers in the pool. The mediate goal is
      > to unify the implementation with the arm constant pool, which will be
      > done in a follow-up CL.
      >
      > Bug: v8:8054
      > Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62209}
      
      TBR=mstarzinger@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com
      
      Bug: v8:8054
      Change-Id: I1e3ab13619a48caad33d77ed8bed86782f9d9674
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664054Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62237}
      e93d244f
  14. 17 Jun, 2019 2 commits
  15. 12 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [arm64,test] Generate code object in assembler tests · 4c0bf17e
      Sigurd Schneider authored
      This is pre-work for a refactoring that changes how heap objects
      are handled in the assembler: Currently, we put the handle location in
      the constant pool, and replace these with the actual heap object when
      we copy the code from the assembler's buffer to the heap.
      
      In the future, we will put a small index in the constant pool, which
      will ultimately enable 32bit constant pool slots for compressed heap
      objects. This small index will be fixed up when we copy the code to
      the heap.
      
      This CL makes the assembler tests copy the code to the heap, which
      ensures that the fix-up phase is actually run.
      
      Change-Id: I80cd69dc57414a3bd0a27f8d558616aadcae05a2
      Bug: v8:7703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647166
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62112}
      4c0bf17e
  16. 04 Jun, 2019 1 commit
  17. 28 May, 2019 1 commit
  18. 27 May, 2019 1 commit
  19. 24 May, 2019 1 commit
  20. 21 May, 2019 1 commit
  21. 02 May, 2019 1 commit
  22. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored
      Failure addressed by not exposing the new test to the jitless environment.
      (jgruber@ on TBR).
      
      New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
      compressed pointers in generated code. Enum name EMBEDDED_OBJECT
      changed to FULL_EMBEDDED_OBJECT.
      
      RelocInfo::[set_]target_object() abstract away the difference between
      FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      
      Compressed embedded objects can only be created at this time on
      x64 with pointer compression turned on. Arm64 constant pools don't
      support compressed objects at this time.
      
      NOPRESUBMIT=true
      
      Bug: v8:7703
      TBR: jgruber@chromium.org
      Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  23. 29 Apr, 2019 4 commits
  24. 05 Mar, 2019 1 commit
  25. 19 Feb, 2019 1 commit
  26. 05 Feb, 2019 2 commits
  27. 30 Jan, 2019 1 commit
  28. 17 Jan, 2019 3 commits
  29. 29 Nov, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  30. 27 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      Revert "[wasm] Add more unit tests for trap handler" · 2fd07376
      Clemens Hammacher authored
      This reverts commit 4644b32e.
      
      Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
      
      Original change's description:
      > [wasm] Add more unit tests for trap handler
      > 
      > The unittests test if the trap handler only handles those traps it
      > is supposed to handle:
      > * Only handle traps when the thread-in-wasm flag is set.
      > * Only handle traps of the right type, i.e. memory access violations.
      > * Only handle traps at recorded instructions.
      > 
      > The tests also test the consistency of the thread-in-wasm flag. I made
      > one change in the trap handler where that consistency could be
      > violated.
      > 
      > All tests are executed with the default trap handler provided by V8,
      > and with the trap handler callback installed in a test signal/exception
      > handler.
      > 
      > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57858}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
      
      Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57861}
      2fd07376