Skip to content

V
V8
Switch branch/tag
  1. 15 Apr, 2021 1 commit
    • Milad Fa's avatar
      PPC/s390: [wasm][x64] Fix OSR shadow stack violation · 80aaae9e
      Milad Fa authored 
      Port 06a2c2e0

Original Commit Message:

    We currently allow OSR (On-Stack Replacement) of arbitrarily deep return
    addresses. This is in direct violation of Intel CET's shadow stack,
    which we plan to enable eventually.

    This change works around this by postponing OSR until after we return to
    the old code. The main changes are:
    - Reserve a slot in Liftoff frames to store the OSR target,
    - Skip the return address modification, and instead store the new code
    pointer in the dedicated slot,
    - Upon returning to the old code, check the slot and do an indirect jump
    to the new code if needed.

    CET also prevents indirect jumps to arbitrary locations, so the last
    point is also a CET violation. Valid indirect jump targets must be
    marked with the ENDBRANCH instruction, which I will do in a follow-up
    CL.

R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: Id972de1ba7556474cb00b377ea3a38eb4332eae3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2828870Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73984}
      80aaae9e
  3. 15 Mar, 2021 1 commit
  5. 10 Mar, 2021 1 commit
  7. 08 Mar, 2021 1 commit
  9. 26 Feb, 2021 1 commit
  11. 25 Feb, 2021 1 commit
  13. 24 Feb, 2021 2 commits
  15. 22 Feb, 2021 3 commits
  17. 19 Feb, 2021 1 commit
  19. 16 Feb, 2021 1 commit
    • Junliang Yan's avatar
      PPC/s390: [liftoff] Cache the instance in a register · a9f2bb0b
      Junliang Yan authored 
      Port adf035fb

Original Commit Message:

    This CL avoids redundant loads of the instance from the frame by caching
    it in a register if possible. This register will be the first one to be
    cleared once we run out of registers (hence it's called a "volatile
    register"). On local tests, this seems to reduce most redundant loads
    within a function, and it also reduces the load for the stack check in
    the function prologue.
    After the stack check, we need to discard the cached instance though,
    since the potential runtime call for the stack check might clobber it.
    This will be addressed in a follow-up CL by re-loading the cached
    instance after the stack check. This is expected to remove another good
    chunk of instance loads, because the instance would initially be
    available in a register when starting the function code.

R=clemensb@chromium.org, midawson@redhat.com, mfarazma@redhat.com
BUG=
LOG=N

Change-Id: I3756ce98d4dfefb44c946a4948f1a6dbe0ce44dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698291Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72791}
      a9f2bb0b
  21. 11 Feb, 2021 2 commits
  23. 10 Feb, 2021 1 commit
  25. 09 Feb, 2021 2 commits
  27. 01 Feb, 2021 1 commit
  29. 27 Jan, 2021 1 commit
  31. 26 Jan, 2021 1 commit
  33. 13 Jan, 2021 2 commits
  35. 12 Jan, 2021 1 commit
  37. 08 Jan, 2021 1 commit
  39. 22 Dec, 2020 1 commit
  41. 16 Dec, 2020 2 commits
  43. 15 Dec, 2020 1 commit
  45. 26 Nov, 2020 1 commit
  47. 24 Nov, 2020 1 commit
  49. 20 Nov, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: Reland "[wasm][memory64] Prepare Liftoff for ptrsize offsets" · 794c2305
      Milad Fa authored 
      Port 1da429fb

Original Commit Message:

    This is a reland of 800307f6, with a
    minimal fix for arm64 (uint64_t -> uintptr_t).

    Original change's description:
    > [wasm][memory64] Prepare Liftoff for ptrsize offsets
    >
    > This CL prepares the LiftoffAssembler interface for uintptr_t offsets.
    > Many places can still only handle 32-bit values, but after this CL we can
    > start storing the offsets as uintptr_t in the memory access immediates.
    > Some TODOs are placed to extend code generation for 64-bit additions, if
    > memory64 is enabled.
    > All of this will be addressed in follow-up CLs.
    >
    > R=manoskouk@chromium.org
    >
    > Bug: v8:10949
    > Change-Id: Id3b9b8aa555ab41f082ba012f4f8d80586c35b89
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529452
    > Commit-Queue: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71236}

R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I87a421ab1fe6e4d0f2098c24ff34a3888631722e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552166Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71317}
      794c2305
  51. 02 Nov, 2020 1 commit
  53. 22 Oct, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: [wasm] Use int type for small offsets · d9829b92
      Milad Fa authored 
      Port ba564604

Original Commit Message:

    The uint32_t type can easily be confused with the memory offsets that
    are currently 32 bit and will become 64 bit with the memory64 proposal.
    Since the offsets into the instance are always small anyway, the type of
    the integer does not really matter, and we should stick to the default
    'int'.

R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: Icfc3b4172984c81355ca4b69b67433892cca7408
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491107Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70720}
      d9829b92
  55. 19 Oct, 2020 1 commit
  57. 15 Oct, 2020 1 commit
  59. 25 Sep, 2020 1 commit
  61. 17 Sep, 2020 1 commit
  63. 16 Sep, 2020 2 commits