1. 01 Oct, 2021 1 commit
  2. 19 Aug, 2021 1 commit
  3. 10 Aug, 2021 1 commit
    • Bruce Dawson's avatar
      Explicitly include windows.h in Win ARM64 files · 67a565c0
      Bruce Dawson authored
      Now that V8 doesn't globally include windows.h we need to explicitly
      include it in source files that need it. This fixes a Windows ARM64
      build break triggered by crrev.com/c/3042215.
      
      I did a test build of ARM64 V8 with and without this patch in order to
      reproduce the errors and confirm that there are no others.
      
      Bug: chromium:796644, chromium:1237067
      Change-Id: I43045fcaab9e6296629775a9705aae6b2066adef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3076019Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
      Auto-Submit: Bruce Dawson <brucedawson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76208}
      67a565c0
  4. 23 Jul, 2021 1 commit
  5. 21 Jul, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Add trap-handler support for arm64 simulator · e312038d
      Clemens Backes authored
      This adds a little {Simulator::ProbeMemory} method that is used from
      several places in the arm64 simulator to test if a memory address can be
      accessed, and trigger a signal from a specific location such that the
      trap-handler can handle it. In case of a trap, the simulator is
      redirected to the landing pad and stops executing the memory
      instruction that triggered the trap.
      
      Standard memory accesses and SIMD memory loads and stores are
      instrumented to probe the memory. This passes all existing tests. In
      case this CL misses certain spots, we can still add them later. This
      will not be a security problem, since we do not use the simulator in
      production.
      
      R=ahaas@chromium.org
      CC=mseaborn@chromium.org, v8-arm-ports@googlegroups.com
      
      Bug: v8:11955
      Change-Id: I52a81341e99fabc5fcf9e41ef4d8dd2226092803
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015557
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75843}
      e312038d
  6. 02 Jul, 2021 1 commit
  7. 10 Jun, 2021 1 commit
  8. 30 Apr, 2021 1 commit
  9. 22 Mar, 2021 1 commit
  10. 12 Mar, 2021 1 commit
    • Andreas Haas's avatar
      [wasm][liftoff][arm64] Avoid x28 even without pointer compression · 8d0f5a04
      Andreas Haas authored
      Due to a recent change Liftoff used different register configurations
      in the pointer-compression and no-pointer-compression setups. This
      caused a mismatch between the registers used by Liftoff and the
      registers spilled by the WasmDebugBreak builtin.
      
      With this CL the same register configuration is used both with and
      without pointer compression. Even without x28 there are 24 registers
      that can be used. Moreover, 24 registers can be spilled without
      padding, which would be needed with 25 registers to preserve stack
      alignment.
      
      Drive-by change: Use Reglist in frame-constants on all platforms.
      
      R=jkummerow@chromium.org
      
      Bug: v8:7581
      Change-Id: Iae2892718e905a7995a3fdd7be7fd4d75bebb3dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752884
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73366}
      8d0f5a04
  11. 15 Feb, 2021 1 commit
  12. 05 Feb, 2021 1 commit
  13. 02 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      [arm64/sim] Add a simple backtrace debug command · 5a0b81b4
      Leszek Swirski authored
      Add a simple backtrace/bt command to the simulator debugger, which does
      the frame-pointer stack walk and dumps pc/fp/sp for each frame.
      
      This is strictly less powerful than the full JS stack dump, but can be
      used to debug issues with corrupted frames that prevent the JS stack
      dumper from working correctly.
      
      Change-Id: I26cc962ab8d22c0a219d6a35548544602aa89418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666688
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72480}
      5a0b81b4
    • Leszek Swirski's avatar
      [arm64/sim] Add a 'sim' gdb command · 1f72df06
      Leszek Swirski authored
      Extract out the command processing from Simulator::Debug(), and expose
      it to gdb as a new 'sim' command. Example usage:
      
          (gdb) sim p x15
          (gdb) sim stack
      
      The sim command will execute that one command, and will return to gdb.
      
      For a list of all commands, you can call
      
          (gdb) sim help
      
      Note that sim won't resume simulator execution until gdb continues
      execution; for example, `sim next` will set a breakpoint on the next
      instruction, and will return to gdb. The user then has to continue
      execution in gdb, at which point the simulator will break. The user can
      then re-enter gdb with the gdb command. This will look like this:
      
          (gdb) sim next
          (gdb) continue
          ...
          sim> gdb
          (gdb) ...
      
      Change-Id: I678e71e2642d8427950b5f7ed65890ceae69e18d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664448
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72479}
      1f72df06
  14. 29 Jan, 2021 1 commit
    • Ng Zhi An's avatar
      [arm64] Fix frame size to account for q registers · 45b99aaa
      Ng Zhi An authored
      In https://crrev.com/c/2645694 we push the full q registers before lazy
      compile, but we did not change the fixed frame size to account for the
      wider registers being pushed.
      
      This manifested in the frame having data like:
      
      (gdb) x/10xg start.ptr_
      0x7f5576ff3eb0: 0x0000000000000000      0x0000336b08202759
      0x7f5576ff3ec0: 0x7ff000007f801000      0x0000000000000000
      0x7f5576ff3ed0: 0x7ff000007f801001      0x0000000000000000
      0x7f5576ff3ee0: 0x7ff000007f801002      0x0000000000000000
      0x7f5576ff3ef0: 0x7ff000007f801003      0x0000000000000000
      
      The GC then walks part of this frame, thinking that 0x7ff000007f801003
      is a heap object, and then crashes.
      
      Add some static_asserts (similar to builtins-x64) to remind ourselves
      that the pushed registers have to match the size in frame constants.
      
      Bug: chromium:1161555,v8:11358
      Change-Id: Ic5138cc17ad44ccab9121ca226f9f812afef72c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656857Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72439}
      45b99aaa
  15. 27 Jan, 2021 1 commit
  16. 19 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [arm][arm64] Use normal fp semantics in JSEntry · a016c9fe
      Seth Brenith authored
      On arm64, Windows Performance Recorder gets confused by the fact that fp
      in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
      caller frame. The expected usage of fp is documented in [1]:
      
        The frame pointer (x29) is required for compatibility with fast stack
        walking used by ETW and other services. It must point to the previous
        {x29, x30} pair on the stack.
      
      In slightly more detail, the Windows function RtlWalkFrameChain is
      responsible for generating stack traces during profiling with Windows
      Performance Recorder, and that function relies on the rule quoted above.
      Notably, it does not make any effort to read the unwinding data that one
      could obtain with RtlLookupFunctionEntry. Stack walks using that data,
      such as those performed by WinDbg and the cctest StackUnwindingWin64,
      work fine.
      
      It would be convenient if we could use fp in a more standard way during
      JSEntry so that Windows profiling tools work correctly. (We can also
      reduce JSEntry by two instructions in doing so.)
      
      Both arm and arm64 currently put a -1 value on the stack at the location
      that fp points to. This could prevent accidental access during the
      epilog of JSEntry, where fp might be zero. However, we believe that this
      protection is no longer necessary, and any bug that causes a read from
      fp during the end of JSEntry would cause various CQ failures.
      
      [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
      
      Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72165}
      a016c9fe
  17. 08 Jan, 2021 1 commit
  18. 24 Nov, 2020 1 commit
  19. 17 Nov, 2020 1 commit
  20. 03 Nov, 2020 1 commit
  21. 02 Nov, 2020 1 commit
  22. 19 Oct, 2020 1 commit
  23. 15 Oct, 2020 1 commit
  24. 23 Sep, 2020 1 commit
  25. 02 Sep, 2020 1 commit
  26. 19 Aug, 2020 1 commit
    • Salome Thirot's avatar
      [arm64] Implement list of allowed return addresses in the deoptimizer · 929dd374
      Salome Thirot authored
      When CFI is enabled this adds a check against this list whenever a new
      return address must be set in a deoptimized frame, as a mitigation for
      ROP attacks.
      The list is known at linking time so that its content and the pointer
      to it can be stored in a read-only memory section.
      The check is performed in the signing function, which is no longer
      generic, as well as when setting the current pc of the frame.
      Since the pc is now only signed when setting the caller's pc, there
      is no need for ReplaceContext anymore.
      
      Bug: v8:10026
      Change-Id: I5e85a62b94722051716fdeba476db383c702a318
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
      Cr-Commit-Position: refs/heads/master@{#69478}
      929dd374
  27. 22 Jun, 2020 1 commit
  28. 16 Jun, 2020 1 commit
  29. 09 Jun, 2020 1 commit
  30. 17 Mar, 2020 1 commit
  31. 16 Mar, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored
      This implements inspection of live registers on breakpoints in Liftoff.
      To that end, the frame pointer of the WasmDebugBreak frame is remembered
      when iterating the stack. Based on a platform-specific implementation of
      {WasmDebugBreakFrameConstants}, the offset of the respective register
      within that frame is computed, and the value is read from the frame.
      
      As a drive-by, the wasm debug side table is storing register codes as
      liftoff codes, which can also store register pairs (needed for i64 on
      32-bit platforms, and for SIMD, which is not supported yet).
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
    • Clemens Backes's avatar
      [wasm] Fix registers spilled in DebugBreak frame · e47f9a9d
      Clemens Backes authored
      The set of registers to spill was wrong. Instead of spilling wasm
      parameter registers (like the WasmCompileLazy builtin), we should spill
      all registers that are being used as Liftoff cache registers.
      This CL defines platform-specific WasmDebugBreakFrameConstants which
      hold the set of registers to spill. This set is used in the builtin, and
      will later be used for inspecting the spilled registers.
      
      In order to iterate bit sets more easily in both direction (MSB to LSB
      or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
      which provides the respective iterators.
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I73ecbdff9b29e244c478b404063c0c9ee25bc821
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102570Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66715}
      e47f9a9d
  32. 20 Feb, 2020 1 commit
  33. 19 Feb, 2020 1 commit
  34. 17 Feb, 2020 1 commit
  35. 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
  36. 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
  37. 03 Feb, 2020 1 commit