Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 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
  5. 10 Feb, 2020 1 commit
  7. 21 Jan, 2020 1 commit
    • Clemens Backes's avatar
      Move decoded asm.js offset table off-heap · 87f09404
      Clemens Backes authored 
      The asm.js offset table exists in two forms: Delta-encoded in a byte
array, as generated during asm translation, and decoded, for faster
lookup.
This CL moves the encoded version from the {AsmWasmData} and
{WasmModuleObject} to the {WasmModule}, and stores it off-heap in a C++
array instead of a {ByteArray}.
Also, it moves the decoded version off-heap by storing it in a C++ data
structure that makes lookup easy, instead of encoding it again in
another {ByteArray}.

This change is a nice refactoring in itself, but it also prepares adding
more information to the offset table. For reconstructing the source code
of an asm.js function, we will need to store the start and end offsets
of the whole function as well (see linked bug).

R=jkummerow@chromium.org

Bug: chromium:667678
Change-Id: I79b789c3122dd8ba803cedc6bfdcc3d4b1fa0fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011108
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65900}
      87f09404
  9. 27 Dec, 2019 1 commit
  11. 03 Dec, 2019 1 commit
  13. 22 Nov, 2019 1 commit
  15. 04 Nov, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 352bbb12
      Dan Elphick authored 
      This is a reland of 855591a5

Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.

Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}

Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64728}
      352bbb12
  17. 31 Oct, 2019 2 commits
  19. 25 Oct, 2019 2 commits
  21. 24 Oct, 2019 2 commits
  23. 18 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "[builtins] Move non-JS linkage builtins code objects into RO_SPACE" · f1ebde88
      Sathya Gunasekaran authored 
      This reverts commit 83f8464f.

Reason for revert: speculative revert for blink linux failure
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/1272

Original change's description:
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
> 
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
> 
> For builtins that go in RO_SPACE a Code object is created that contains
> no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
> but is there to allow the runtime to continue to work since it expects
> a Code object.
> 
> This reduces code_space from ~152k to ~40k (-112k) and increases
> read_only_space from 33k to 108k (+75k) in the snapshot.
> 
> Bug: v8:7464, v8:9821, v8:9338, v8:8127
> Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64377}

TBR=mstarzinger@chromium.org,jgruber@chromium.org,delphick@chromium.org

Change-Id: I4cf38e9370280acdd2de718ca527776ebc509003
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464, v8:9821, v8:9338, v8:8127
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868621Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64383}
      f1ebde88
    • Dan Elphick's avatar
      [builtins] Move non-JS linkage builtins code objects into RO_SPACE · 83f8464f
      Dan Elphick authored 
      Creates an allow-list of builtins that can still go in code_space
including all TFJ builtins and a small manual list that should be pared
down in the future.

For builtins that go in RO_SPACE a Code object is created that contains
no code at all (shrinking its size from 96 bytes to 64 bytes on x64),
but is there to allow the runtime to continue to work since it expects
a Code object.

This reduces code_space from ~152k to ~40k (-112k) and increases
read_only_space from 33k to 108k (+75k) in the snapshot.

Bug: v8:7464, v8:9821, v8:9338, v8:8127
Change-Id: Icc8bfc722bb267a2bcc17e2f1e27bef7f02f2376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795358
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64377}
      83f8464f
  25. 08 Oct, 2019 1 commit
  27. 26 Sep, 2019 1 commit
  29. 13 Sep, 2019 1 commit
  31. 11 Sep, 2019 1 commit
  33. 05 Sep, 2019 1 commit
  35. 22 Aug, 2019 3 commits
    • Jakob Gruber's avatar
      Reland "[compiler] Track the maximal unoptimized frame size" · 95e26e49
      Jakob Gruber authored 
      This is a reland of 1e472c42

No change, this was a speculative revert to unblock the roll.

TBR=jgruber

Original change's description:
> [compiler] Track the maximal unoptimized frame size
>
> This is another step towards considering the unoptimized frame size in
> stack checks within optimized code.
>
> With the changes in this CL, we now keep track of the maximal
> unoptimized frame size of the function that is currently being
> compiled. An optimized function may inline multiple unoptimized
> functions, so a single optimized frame can deopt to multiple
> frames. The real frame size thus differs in different parts of the
> optimized function.
>
> We only care about the maximal frame size, which we calculate
> conservatively as an over-approximation, and track in
> InstructionSelector::max_unoptimized_frame_height_ for now. In future
> work, this value will be passed on to codegen, where it will be
> applied as an offset to the stack pointer during the stack check.
>
> (The motivation behind this is to avoid stack overflows through deopts,
> caused by size differences between optimized and unoptimized frames.)
>
> Note that this offset only ensure that the topmost optimized frame can
> deopt without overflowing the stack limit. That's fine, because we only
> deopt optimized frames one at a time. Other (non-topmost) frames are
> only deoptimized once they are returned to.
>
> Drive-by: Print variable and total frame height in --trace-deopt.
>
> Bug: v8:9534
> Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63330}

Bug: v8:9534
Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63356}
      95e26e49
    • Bill Budge's avatar
      Revert "[compiler] Track the maximal unoptimized frame size" · 98b5c49f
      Bill Budge authored 
      This reverts commit 1e472c42.

Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run:

https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465

Original change's description:
> [compiler] Track the maximal unoptimized frame size
> 
> This is another step towards considering the unoptimized frame size in
> stack checks within optimized code.
> 
> With the changes in this CL, we now keep track of the maximal
> unoptimized frame size of the function that is currently being
> compiled. An optimized function may inline multiple unoptimized
> functions, so a single optimized frame can deopt to multiple
> frames. The real frame size thus differs in different parts of the
> optimized function.
> 
> We only care about the maximal frame size, which we calculate
> conservatively as an over-approximation, and track in
> InstructionSelector::max_unoptimized_frame_height_ for now. In future
> work, this value will be passed on to codegen, where it will be
> applied as an offset to the stack pointer during the stack check.
> 
> (The motivation behind this is to avoid stack overflows through deopts,
> caused by size differences between optimized and unoptimized frames.)
> 
> Note that this offset only ensure that the topmost optimized frame can
> deopt without overflowing the stack limit. That's fine, because we only
> deopt optimized frames one at a time. Other (non-topmost) frames are
> only deoptimized once they are returned to.
> 
> Drive-by: Print variable and total frame height in --trace-deopt.
> 
> Bug: v8:9534
> Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63330}

TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org

Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63350}
      98b5c49f
    • Jakob Gruber's avatar
      [compiler] Track the maximal unoptimized frame size · 1e472c42
      Jakob Gruber authored 
      This is another step towards considering the unoptimized frame size in
stack checks within optimized code.

With the changes in this CL, we now keep track of the maximal
unoptimized frame size of the function that is currently being
compiled. An optimized function may inline multiple unoptimized
functions, so a single optimized frame can deopt to multiple
frames. The real frame size thus differs in different parts of the
optimized function.

We only care about the maximal frame size, which we calculate
conservatively as an over-approximation, and track in
InstructionSelector::max_unoptimized_frame_height_ for now. In future
work, this value will be passed on to codegen, where it will be
applied as an offset to the stack pointer during the stack check.

(The motivation behind this is to avoid stack overflows through deopts,
caused by size differences between optimized and unoptimized frames.)

Note that this offset only ensure that the topmost optimized frame can
deopt without overflowing the stack limit. That's fine, because we only
deopt optimized frames one at a time. Other (non-topmost) frames are
only deoptimized once they are returned to.

Drive-by: Print variable and total frame height in --trace-deopt.

Bug: v8:9534
Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63330}
      1e472c42
  37. 20 Aug, 2019 2 commits
  39. 29 Jul, 2019 1 commit
  41. 12 Jul, 2019 1 commit
  43. 11 Jul, 2019 1 commit
  45. 10 Jul, 2019 1 commit
  47. 27 Jun, 2019 1 commit
  49. 12 Jun, 2019 1 commit
  51. 29 May, 2019 1 commit
  53. 28 May, 2019 1 commit
  55. 24 May, 2019 2 commits
  57. 23 May, 2019 2 commits
  59. 22 May, 2019 1 commit