Issue 10026 in v8: CFI measures for arm64

57 views
Skip to first unread message

georgia.… via monorail

unread,
Nov 27, 2019, 10:01:28 AM11/27/19
to v8-re...@googlegroups.com
Status: Untriaged
Owner: ----
CC: mvstan...@chromium.org, ne...@chromium.org, rmci...@chromium.org, mstar...@chromium.org
Type: Bug

New issue 10026 by georgia....@arm.com: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026

This is a tracking bug for implementing CFI measures (pointer authentication, BTI) for arm64.

See https://chromium-review.googlesource.com/c/v8/v8/+/1373782/ for the first part of this.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

n… via monorail

unread,
Nov 27, 2019, 10:56:12 AM11/27/19
to v8-re...@googlegroups.com
Updates:
Components: Compiler

Comment #1 on issue 10026 by ne...@chromium.org: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c1

(No comment was entered for this change.)

habl… via monorail

unread,
Dec 10, 2019, 9:53:08 AM12/10/19
to v8-re...@googlegroups.com
Updates:
Labels: Priority-2 Type-FeatureRequest
Status: Available

Comment #2 on issue 10026 by hab...@chromium.org: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c2

n… via monorail

unread,
Jan 17, 2020, 7:01:18 AM1/17/20
to v8-re...@googlegroups.com
Updates:
Owner: georgia....@arm.com
Status: Assigned

Comment #3 on issue 10026 by ne...@chromium.org: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c3

n… via monorail

unread,
Jan 17, 2020, 7:01:30 AM1/17/20
to v8-re...@googlegroups.com
Updates:
Status: Started

Comment #4 on issue 10026 by ne...@chromium.org: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c4

bugdroid via monorail

unread,
Feb 3, 2020, 10:23:17 AM2/3/20
to v8-re...@googlegroups.com

Comment #5 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c5

The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/4eac274d32a756fcb26d5c5e6669303ac6b8a98f

commit 4eac274d32a756fcb26d5c5e6669303ac6b8a98f
Author: Georgia Kouveli <georgia...@arm.com>
Date: Mon Feb 03 15:21:59 2020

[arm64] Add support for BTI instruction

Bug: v8:10026
Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66082}

[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/assembler-arm64.cc
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/assembler-arm64.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/constants-arm64.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/instructions-arm64.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/diagnostics/arm64/disasm-arm64.cc
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/execution/arm64/simulator-arm64.cc
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/src/execution/arm64/simulator-arm64.h
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/4eac274d32a756fcb26d5c5e6669303ac6b8a98f/test/cctest/test-disasm-arm64.cc

bugdroid via monorail

unread,
Feb 12, 2020, 9:01:21 AM2/12/20
to v8-re...@googlegroups.com

Comment #6 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c6


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/137bfe47c9af56dcf8466e2736579616e51b86df

commit 137bfe47c9af56dcf8466e2736579616e51b86df
Author: Georgia Kouveli <georgia...@arm.com>
Date: Wed Feb 12 13:59:44 2020

[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...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}

[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/BUILD.gn
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/compiler/backend/arm64/code-generator-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/compiler/backend/arm64/unwinding-info-writer-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/debug/arm64/debug-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/arm/deoptimizer-arm.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/ia32/deoptimizer-ia32.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/mips/deoptimizer-mips.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/mips64/deoptimizer-mips64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/ppc/deoptimizer-ppc.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/s390/deoptimizer-s390.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/deoptimizer/x64/deoptimizer-x64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/diagnostics/unwinder.cc
[add] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/frames-inl.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/frames.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/frames.h
[add] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/pointer-authentication-dummy.h
[add] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/execution/pointer-authentication.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/regexp/arm64/regexp-macro-assembler-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/src/regexp/regexp-macro-assembler.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/test/cctest/cctest.h
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/test/cctest/test-sampler-api.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/test/cctest/test-unwinder-code-pages.cc
[modify] https://crrev.com/137bfe47c9af56dcf8466e2736579616e51b86df/test/cctest/test-unwinder.cc

bugdroid via monorail

unread,
Feb 12, 2020, 10:11:27 AM2/12/20
to v8-re...@googlegroups.com

Comment #7 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c7


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6a9a67d9420282b3528aa29fdcff4ff9e3661621

commit 6a9a67d9420282b3528aa29fdcff4ff9e3661621
Author: Nico Hartmann <nicoha...@chromium.org>
Date: Wed Feb 12 15:07:54 2020

Revert "[arm64] Protect return addresses stored on stack"

This reverts commit 137bfe47c9af56dcf8466e2736579616e51b86df.

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

TBR=rmci...@chromium.org,mstar...@chromium.org,ne...@chromium.org,georgia...@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/+/2051952
Reviewed-by: Nico Hartmann <nicoha...@chromium.org>
Commit-Queue: Nico Hartmann <nicoha...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}

[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/BUILD.gn
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/compiler/backend/arm64/code-generator-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/compiler/backend/arm64/unwinding-info-writer-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/debug/arm64/debug-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/arm/deoptimizer-arm.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/ia32/deoptimizer-ia32.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/mips/deoptimizer-mips.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/mips64/deoptimizer-mips64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/ppc/deoptimizer-ppc.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/s390/deoptimizer-s390.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/deoptimizer/x64/deoptimizer-x64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/diagnostics/unwinder.cc
[delete] https://crrev.com/33e8519b5e429bbf34e255799e2571b769369477/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/execution/frames-inl.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/execution/frames.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/execution/frames.h
[delete] https://crrev.com/33e8519b5e429bbf34e255799e2571b769369477/src/execution/pointer-authentication-dummy.h
[delete] https://crrev.com/33e8519b5e429bbf34e255799e2571b769369477/src/execution/pointer-authentication.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/regexp/arm64/regexp-macro-assembler-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/src/regexp/regexp-macro-assembler.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/test/cctest/cctest.h
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/test/cctest/test-sampler-api.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/test/cctest/test-unwinder-code-pages.cc
[modify] https://crrev.com/6a9a67d9420282b3528aa29fdcff4ff9e3661621/test/cctest/test-unwinder.cc

nicohart… via monorail

unread,
Feb 12, 2020, 10:16:12 AM2/12/20
to v8-re...@googlegroups.com

Comment #8 on issue 10026 by nicoha...@chromium.org: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c8

Speculatively reverted this CL as it failed a V8 arm debug bot that closed the tree. Can you please take a look at that and reland when it is fixed or clear that this CL did not cause the issue.

georgia.… via monorail

unread,
Feb 12, 2020, 10:33:03 AM2/12/20
to v8-re...@googlegroups.com

Comment #9 on issue 10026 by georgia....@arm.com: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c9

It looks like a few death tests failed to create a tmp file:

[WARNING] ../../third_party/googletest/src/googletest/src/gtest-port.cc:1118:: Failed to create tmp file /tmp/captured_stream.goKNBw for test; does the test have access to the /tmp directory?
abort: no reason

[ FATAL ] ../../third_party/googletest/src/googletest/src/gtest-port.cc:1144:: Failed to open tmp file /tmp/captured_stream.goKNBw for capturing stream.
Aborted

Looks like some other assertion failures that are printed are meant to fire, that's what those tests try to check.

Any idea what would cause the tmp file not to be created? (It's created in googletest so I don't see how my CL would have affected this).

bugdroid via monorail

unread,
Feb 13, 2020, 7:27:43 AM2/13/20
to v8-re...@googlegroups.com

Comment #10 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c10


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/73f88b5f69077ef33169361f884f31872a6d56ac

commit 73f88b5f69077ef33169361f884f31872a6d56ac
Author: Georgia Kouveli <georgia...@arm.com>
Date: Thu Feb 13 12:26:25 2020

Reland "[arm64] Protect return addresses stored on stack"

This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df
Bug: v8:10026
Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958
Reviewed-by: Georg Neis <ne...@chromium.org>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#66254}

[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/BUILD.gn
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/compiler/backend/arm64/code-generator-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/compiler/backend/arm64/unwinding-info-writer-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/debug/arm64/debug-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/arm/deoptimizer-arm.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/ia32/deoptimizer-ia32.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/mips/deoptimizer-mips.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/mips64/deoptimizer-mips64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/ppc/deoptimizer-ppc.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/s390/deoptimizer-s390.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/deoptimizer/x64/deoptimizer-x64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/diagnostics/unwinder.cc
[add] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/frames-inl.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/frames.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/frames.h
[add] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/pointer-authentication-dummy.h
[add] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/execution/pointer-authentication.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/regexp/arm64/regexp-macro-assembler-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/src/regexp/regexp-macro-assembler.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/test/cctest/cctest.h
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/test/cctest/test-sampler-api.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/test/cctest/test-unwinder-code-pages.cc
[modify] https://crrev.com/73f88b5f69077ef33169361f884f31872a6d56ac/test/cctest/test-unwinder.cc

bugdroid via monorail

unread,
Mar 17, 2020, 1:52:51 PM3/17/20
to v8-re...@googlegroups.com

Comment #11 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c11


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6

commit ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6
Author: Georgia Kouveli <georgia...@arm.com>
Date: Tue Mar 17 17:52:28 2020

[arm64] Use BTI instructions for forward CFI

Generate a BTI instruction at each target of an indirect branch
(BR/BLR). An indirect branch that doesn't jump to a BTI instruction
will generate an exception on a BTI-enabled core. On cores that do
not support the BTI extension, the BTI instruction is a NOP.

Targets of indirect branch instructions include, among other things,
function entrypoints, exception handlers and jump tables. Lazy deopt
exits can potentially be reached through an indirect branch when an
exception is thrown, so they also get an additional BTI instruction.

Bug: v8:10026
Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315

Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Reviewed-by: Clemens Backes <clem...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66751}

[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/BUILD.gn
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/base/platform/platform-posix.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/builtins/builtins.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/builtins/setup-builtins-internal.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/arm/macro-assembler-arm.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/arm/macro-assembler-arm.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/ia32/macro-assembler-ia32.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/ia32/macro-assembler-ia32.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/mips/macro-assembler-mips.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/mips/macro-assembler-mips.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/mips64/macro-assembler-mips64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/mips64/macro-assembler-mips64.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/ppc/macro-assembler-ppc.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/ppc/macro-assembler-ppc.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/s390/macro-assembler-s390.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/s390/macro-assembler-s390.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/x64/macro-assembler-x64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/codegen/x64/macro-assembler-x64.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/compiler/backend/arm64/code-generator-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/compiler/backend/code-generator.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/compiler/backend/code-generator.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/compiler/backend/instruction.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/compiler/backend/jump-threading.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/arm/deoptimizer-arm.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/ia32/deoptimizer-ia32.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/mips/deoptimizer-mips.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/mips64/deoptimizer-mips64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/ppc/deoptimizer-ppc.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/s390/deoptimizer-s390.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/deoptimizer/x64/deoptimizer-x64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/execution/arm64/simulator-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/flags/flag-definitions.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/objects/code-inl.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/objects/code.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/regexp/arm64/regexp-macro-assembler-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/regexp/arm64/regexp-macro-assembler-arm64.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/regexp/regexp-compiler.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/regexp/regexp-macro-assembler.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/snapshot/embedded/platform-embedded-file-writer-generic.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/wasm/baseline/liftoff-compiler.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/wasm/jump-table-assembler.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/src/wasm/jump-table-assembler.h
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/cctest/compiler/test-code-generator.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/cctest/test-icache.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/cctest/test-regexp.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/cctest/test-sync-primitives-arm64.cc
[modify] https://crrev.com/ea82d0311b3bd1ab9f92b59e5b5c51bfd5ef87b6/test/unittests/assembler/turbo-assembler-arm64-unittest.cc

bugdroid via monorail

unread,
Apr 2, 2020, 8:53:34 AM4/2/20
to v8-re...@googlegroups.com
Updates:
Labels: merge-merged-8.3

Comment #12 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c12


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/4eac274d32a756fcb26d5c5e6669303ac6b8a98f

commit 4eac274d32a756fcb26d5c5e6669303ac6b8a98f
Author: Georgia Kouveli <georgia...@arm.com>

Date: Mon Feb 03 15:21:59 2020

[arm64] Add support for BTI instruction

Bug: v8:10026
Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:00:09 AM4/2/20
to v8-re...@googlegroups.com

Comment #14 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c14


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6a9a67d9420282b3528aa29fdcff4ff9e3661621

commit 6a9a67d9420282b3528aa29fdcff4ff9e3661621
Author: Nico Hartmann <nicoha...@chromium.org>
Date: Wed Feb 12 15:07:54 2020

Revert "[arm64] Protect return addresses stored on stack"

This reverts commit 137bfe47c9af56dcf8466e2736579616e51b86df.

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:00:11 AM4/2/20
to v8-re...@googlegroups.com

Comment #13 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c13


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/137bfe47c9af56dcf8466e2736579616e51b86df

commit 137bfe47c9af56dcf8466e2736579616e51b86df
Author: Georgia Kouveli <georgia...@arm.com>

Date: Wed Feb 12 13:59:44 2020

[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...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}

bugdroid via monorail

unread,
Apr 2, 2020, 9:00:50 AM4/2/20
to v8-re...@googlegroups.com

Comment #15 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c15


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/73f88b5f69077ef33169361f884f31872a6d56ac

commit 73f88b5f69077ef33169361f884f31872a6d56ac
Author: Georgia Kouveli <georgia...@arm.com>

Date: Thu Feb 13 12:26:25 2020

Reland "[arm64] Protect return addresses stored on stack"

This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@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/+/2051958
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:14:00 AM4/2/20
to v8-re...@googlegroups.com

Comment #16 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c16


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/4eac274d32a756fcb26d5c5e6669303ac6b8a98f

commit 4eac274d32a756fcb26d5c5e6669303ac6b8a98f
Author: Georgia Kouveli <georgia...@arm.com>

Date: Mon Feb 03 15:21:59 2020

[arm64] Add support for BTI instruction

Bug: v8:10026
Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:20:37 AM4/2/20
to v8-re...@googlegroups.com

Comment #17 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c17


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/137bfe47c9af56dcf8466e2736579616e51b86df

commit 137bfe47c9af56dcf8466e2736579616e51b86df
Author: Georgia Kouveli <georgia...@arm.com>

Date: Wed Feb 12 13:59:44 2020

[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...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:20:39 AM4/2/20
to v8-re...@googlegroups.com

Comment #18 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c18


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6a9a67d9420282b3528aa29fdcff4ff9e3661621

commit 6a9a67d9420282b3528aa29fdcff4ff9e3661621
Author: Nico Hartmann <nicoha...@chromium.org>
Date: Wed Feb 12 15:07:54 2020

Revert "[arm64] Protect return addresses stored on stack"

This reverts commit 137bfe47c9af56dcf8466e2736579616e51b86df.

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

bugdroid via monorail

unread,
Apr 2, 2020, 9:21:19 AM4/2/20
to v8-re...@googlegroups.com

Comment #19 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c19


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/73f88b5f69077ef33169361f884f31872a6d56ac

commit 73f88b5f69077ef33169361f884f31872a6d56ac
Author: Georgia Kouveli <georgia...@arm.com>

Date: Thu Feb 13 12:26:25 2020

Reland "[arm64] Protect return addresses stored on stack"

This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df

bugdroid via monorail

unread,
Apr 2, 2020, 9:35:26 AM4/2/20
to v8-re...@googlegroups.com

Comment #20 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c20


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/4eac274d32a756fcb26d5c5e6669303ac6b8a98f

commit 4eac274d32a756fcb26d5c5e6669303ac6b8a98f
Author: Georgia Kouveli <georgia...@arm.com>

Date: Mon Feb 03 15:21:59 2020

[arm64] Add support for BTI instruction

Bug: v8:10026
Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:42:01 AM4/2/20
to v8-re...@googlegroups.com

Comment #21 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c21


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/137bfe47c9af56dcf8466e2736579616e51b86df

commit 137bfe47c9af56dcf8466e2736579616e51b86df
Author: Georgia Kouveli <georgia...@arm.com>

Date: Wed Feb 12 13:59:44 2020

[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...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 9:42:03 AM4/2/20
to v8-re...@googlegroups.com

Comment #22 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c22


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6a9a67d9420282b3528aa29fdcff4ff9e3661621

commit 6a9a67d9420282b3528aa29fdcff4ff9e3661621
Author: Nico Hartmann <nicoha...@chromium.org>
Date: Wed Feb 12 15:07:54 2020

Revert "[arm64] Protect return addresses stored on stack"

This reverts commit 137bfe47c9af56dcf8466e2736579616e51b86df.

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

bugdroid via monorail

unread,
Apr 2, 2020, 9:42:43 AM4/2/20
to v8-re...@googlegroups.com

Comment #23 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c23


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/73f88b5f69077ef33169361f884f31872a6d56ac

commit 73f88b5f69077ef33169361f884f31872a6d56ac
Author: Georgia Kouveli <georgia...@arm.com>

Date: Thu Feb 13 12:26:25 2020

Reland "[arm64] Protect return addresses stored on stack"

This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df

bugdroid via monorail

unread,
Apr 2, 2020, 10:02:56 AM4/2/20
to v8-re...@googlegroups.com

Comment #24 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c24


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/4eac274d32a756fcb26d5c5e6669303ac6b8a98f

commit 4eac274d32a756fcb26d5c5e6669303ac6b8a98f
Author: Georgia Kouveli <georgia...@arm.com>

Date: Mon Feb 03 15:21:59 2020

[arm64] Add support for BTI instruction

Bug: v8:10026
Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 10:09:26 AM4/2/20
to v8-re...@googlegroups.com

Comment #26 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c26


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6a9a67d9420282b3528aa29fdcff4ff9e3661621

commit 6a9a67d9420282b3528aa29fdcff4ff9e3661621
Author: Nico Hartmann <nicoha...@chromium.org>
Date: Wed Feb 12 15:07:54 2020

Revert "[arm64] Protect return addresses stored on stack"

This reverts commit 137bfe47c9af56dcf8466e2736579616e51b86df.

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>

bugdroid via monorail

unread,
Apr 2, 2020, 10:09:32 AM4/2/20
to v8-re...@googlegroups.com

Comment #25 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c25


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/137bfe47c9af56dcf8466e2736579616e51b86df

commit 137bfe47c9af56dcf8466e2736579616e51b86df
Author: Georgia Kouveli <georgia...@arm.com>

Date: Wed Feb 12 13:59:44 2020

[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...@arm.com>
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}

bugdroid via monorail

unread,
Apr 2, 2020, 10:10:12 AM4/2/20
to v8-re...@googlegroups.com

Comment #27 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c27


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/73f88b5f69077ef33169361f884f31872a6d56ac

commit 73f88b5f69077ef33169361f884f31872a6d56ac
Author: Georgia Kouveli <georgia...@arm.com>

Date: Thu Feb 13 12:26:25 2020

Reland "[arm64] Protect return addresses stored on stack"

This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df

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...@arm.com>
> Reviewed-by: Ross McIlroy <rmci...@chromium.org>
> Reviewed-by: Georg Neis <ne...@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

bugdroid via monorail

unread,
Jun 16, 2020, 7:04:20 AM6/16/20
to v8-re...@googlegroups.com

Comment #29 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c29


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/c65c1c10a58d4e705497186f301696acd87ef828

commit c65c1c10a58d4e705497186f301696acd87ef828
Author: Georgia Kouveli <georgia...@arm.com>
Date: Tue Jun 16 11:02:59 2020

[arm64] Use B instruction key for return address signing

The C++ code uses the A instruction key for return address signing,
which is the default for Clang and GCC when the -mbranch-protection
option is used (although this can be configured to use the B key).

Using the B key for JS means that it's not possible to use an A key
signing gadget to replace a return address signed with the B key and
vice-versa. This should offer a degree of separation from the C++ side.

Bug: v8:10026
Change-Id: Ia9dcc7ae7096c96b4a271efbe25fc02940f6fc8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242953

Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#68360}

[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/assembler-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/assembler-arm64.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/constants-arm64.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/codegen/arm64/macro-assembler-arm64.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/diagnostics/arm64/disasm-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/execution/arm64/pointer-auth-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/execution/arm64/simulator-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/src/execution/arm64/simulator-arm64.h
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/c65c1c10a58d4e705497186f301696acd87ef828/test/cctest/test-disasm-arm64.cc

bugdroid via monorail

unread,
Jun 17, 2020, 8:08:00 AM6/17/20
to v8-re...@googlegroups.com

Comment #30 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c30


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/bf383a87180e5d6cf78f9381a458fb0e6333e886

commit bf383a87180e5d6cf78f9381a458fb0e6333e886
Author: Georgia Kouveli <georgia...@arm.com>
Date: Wed Jun 17 12:07:18 2020

[arm64][cfi] Skip authenticating return addresses in the profiler

The SafeStackFrameIterator, used in the profiler, sometimes uses the
link register instead of a return address stored on the stack, to get
more accurate results. This happens in particular for bytecode handlers
that do not create a stack frame. Authentication of PC for those frames
would fail in the SafeStackFrameIterator, as the "PC address" would not
point to a stack location with a signed return address, but instead to
a member of the SafeStackFrameIterator class where the value of the link
register was stored. We address this by skipping authentication of PCs
in the profiler.

Bug: v8:10026
Change-Id: I331c6c68e703db766be1891efffa69c2f9794e8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242954
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#68388}

[modify] https://crrev.com/bf383a87180e5d6cf78f9381a458fb0e6333e886/src/execution/frames-inl.h
[modify] https://crrev.com/bf383a87180e5d6cf78f9381a458fb0e6333e886/src/execution/frames.cc
[modify] https://crrev.com/bf383a87180e5d6cf78f9381a458fb0e6333e886/src/execution/frames.h
[modify] https://crrev.com/bf383a87180e5d6cf78f9381a458fb0e6333e886/src/profiler/tick-sample.cc

bugdroid via monorail

unread,
Jul 2, 2020, 9:16:36 AM7/2/20
to v8-re...@googlegroups.com

Comment #31 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c31


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/ee229d9e9653714efa6d5e30c00729d81d7ba6fc

commit ee229d9e9653714efa6d5e30c00729d81d7ba6fc
Author: Georgia Kouveli <georgia...@arm.com>
Date: Thu Jul 02 13:13:09 2020

[arm64][cfi] Use x16/x17 for tail calls

Using x16/x17 for tail calls allows us to use a "BTI c" instead
of "BTI jc" landing pad. This means that we cannot enter functions
with a jump to a register other than x16/x17 anymore.

Bug: v8:10026
Change-Id: If5af1af861acc19f9e0dfc19c38d6a57a6fb6b6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276049
Reviewed-by: Georg Neis <ne...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#68655}

[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/src/codegen/arm64/macro-assembler-arm64-inl.h
[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/src/compiler/backend/arm64/code-generator-arm64.cc
[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/ee229d9e9653714efa6d5e30c00729d81d7ba6fc/test/cctest/wasm/test-jump-table-assembler.cc

bugdroid via monorail

unread,
Aug 19, 2020, 9:33:48 AM8/19/20
to v8-re...@googlegroups.com

Comment #32 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c32


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/929dd3748e9e29b8c858fa2e587187b84cdcfeac

commit 929dd3748e9e29b8c858fa2e587187b84cdcfeac
Author: Salome Thirot <salome...@arm.com>
Date: Wed Aug 19 13:32:46 2020

[arm64] Implement list of allowed return addresses in the deoptimizer

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/+/2287490
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph....@arm.com>
Cr-Commit-Position: refs/heads/master@{#69478}

[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/BUILD.gn
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/deoptimizer/arm64/deoptimizer-arm64.cc
[add] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/deoptimizer/deoptimizer-cfi-builtins.cc
[add] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/deoptimizer/deoptimizer-cfi-empty.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/execution/isolate.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/execution/isolate.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/execution/pointer-authentication-dummy.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/execution/pointer-authentication.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/embedded-file-writer.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/embedded-file-writer.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-aix.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-aix.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-base.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-generic.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-generic.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-mac.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-mac.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-win.cc
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/src/snapshot/embedded/platform-embedded-file-writer-win.h
[modify] https://crrev.com/929dd3748e9e29b8c858fa2e587187b84cdcfeac/test/cctest/test-unwinder.cc

bugdroid via monorail

unread,
Nov 17, 2020, 1:09:47 PM11/17/20
to v8-re...@googlegroups.com

Comment #33 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c33


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/6d10bcb71118b336a721838736195cc417a39165

commit 6d10bcb71118b336a721838736195cc417a39165
Author: Georgia Kouveli <georgia...@arm.com>
Date: Tue Nov 17 18:08:18 2020

[arm64] Mark embedded builtins as supporting BTI

Use the recently added -mmark-bti-property Clang flag to add
GNU_PROPERTY_AARCH64_FEATURE_1_BTI to the ELF GNU program properties.

Bug: v8:10026
Change-Id: Id35a60c9f5a8b3019313d56a142ab8f481e095a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543934
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#71240}

[modify] https://crrev.com/6d10bcb71118b336a721838736195cc417a39165/BUILD.gn
[modify] https://crrev.com/6d10bcb71118b336a721838736195cc417a39165/src/snapshot/embedded/platform-embedded-file-writer-generic.cc

bugdroid via monorail

unread,
Jan 12, 2021, 5:54:22 AM1/12/21
to v8-re...@googlegroups.com

Comment #34 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c34


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/ec598bbe552526d3ea393264b08a97b1642613f6

commit ec598bbe552526d3ea393264b08a97b1642613f6
Author: Georgia Kouveli <georgia...@arm.com>
Date: Tue Jan 12 10:53:39 2021

[arm64] Fix setting up of frame pointer in RegExpMacroAssembler

The frame pointer did not point to the previous frame pointer, which
made the stack non-iterable with SafeStackFrameIterator.

This can cause pointer authentication failures when CFI is enabled,
as we expect the value stored above the previous frame pointer to
be a return address.

Bug: v8:10026
Change-Id: Ia55181038b1b277d0a6df519f1e7f61859847b1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614429
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Reviewed-by: Jakob Gruber <jgr...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#72036}

[modify] https://crrev.com/ec598bbe552526d3ea393264b08a97b1642613f6/src/regexp/arm64/regexp-macro-assembler-arm64.h
[modify] https://crrev.com/ec598bbe552526d3ea393264b08a97b1642613f6/src/regexp/arm64/regexp-macro-assembler-arm64.cc

bugdroid via monorail

unread,
Feb 1, 2021, 6:43:45 AM2/1/21
to v8-re...@googlegroups.com

Comment #35 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c35


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/07b03b83537dfaee868b7cf42ea4c764981487c3

commit 07b03b83537dfaee868b7cf42ea4c764981487c3
Author: Georgia Kouveli <georgia...@arm.com>
Date: Mon Feb 01 11:42:55 2021

[builtins] Clear c_entry_fp when entering JS and at exception path

c_entry_fp is normally cleared in `LeaveExitFrame`, but we adjust
the frame without it in the exception path.

This can cause the SafeStackFrameIterator to assume we have an exit
frame and iterate over frames incorrectly, which for arm64 can
cause pointer authentication failures with CFI enabled. Even without
the pointer authentication failure, we iterate over frames incorrectly,
so make this change for other architectures too.

Also clear c_entry_fp in the beginning of JSEntry, after pushing it
on the stack. Not doing this doesn't cause pointer authentication
failures, but it will make the SafeStackFrameIterator assume we
are executing C++ and miss the JS frames on top.

Bug: v8:10026
Change-Id: Ie94834920f51e9f1cc5c1c775596726b61fc0507
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642256

Reviewed-by: Jakob Gruber <jgr...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>

bugdroid via monorail

unread,
Feb 4, 2021, 1:44:10 AM2/4/21
to v8-re...@googlegroups.com

Comment #36 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c36


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/996a2dd9b915988627586ad1db1558cc103189cd

commit 996a2dd9b915988627586ad1db1558cc103189cd
Author: Liu Yu <li...@loongson.cn>
Date: Thu Feb 04 06:40:03 2021

[mips][builtins] Clear c_entry_fp when entering JS and at exception path

Port: 07b03b83537dfaee868b7cf42ea4c764981487c3

Bug: v8:10026
Change-Id: Ia9e5f420253a4fb3726a4064ed2471684af610e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2670168
Auto-Submit: Liu yu <li...@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojia...@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojia...@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#72521}

[modify] https://crrev.com/996a2dd9b915988627586ad1db1558cc103189cd/src/builtins/mips64/builtins-mips64.cc
[modify] https://crrev.com/996a2dd9b915988627586ad1db1558cc103189cd/src/builtins/mips/builtins-mips.cc

bugdroid via monorail

unread,
Feb 5, 2021, 5:24:22 AM2/5/21
to v8-re...@googlegroups.com

Comment #37 on issue 10026 by bugdroid: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c37


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9

commit 35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9
Author: Georgia Kouveli <georgia...@arm.com>
Date: Fri Feb 05 10:23:40 2021

[arm64][cfi] Enable `sim_abort_on_bad_auth` by default.

This requires a small fix in {Push,Pop}CalleeSavedRegisters, where
the return address was signed/authenticated at the wrong point,
which meant the stack pointer used as modifier was different from
the one the StackFrameIterator expected.

Bug: v8:10026
Change-Id: Idebd2ee8f07312b5e99dd2ea5181fc7a7e4a87bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667861
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Reviewed-by: Jakob Gruber <jgr...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72542}

[modify] https://crrev.com/35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9/src/codegen/arm64/macro-assembler-arm64.cc
[modify] https://crrev.com/35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9/src/flags/flag-definitions.h
[modify] https://crrev.com/35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9/test/cctest/test-assembler-arm64.cc
[modify] https://crrev.com/35b4f3a0e50f899f701c7d2e5bca7fe350e9b8c9/test/cctest/test-pointer-auth-arm64.cc

Git Watcher via monorail

unread,
Mar 18, 2021, 8:37:08 AM3/18/21
to v8-re...@googlegroups.com

Comment #38 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c38


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/8de57ed75f4051d98cb93852c06d744d05cf8989

commit 8de57ed75f4051d98cb93852c06d744d05cf8989
Author: Georgia Kouveli <georgia...@arm.com>
Date: Wed Mar 17 10:40:21 2021

[cppgc][arm64][cfi] Add PAC/AUT instructions to `PushAllRegistersAndIterateStack`.

Bug: v8:10026
Change-Id: Ie040d36d9a98943f97236998df53408bb060d028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2764760
Reviewed-by: Ross McIlroy <rmci...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#73506}

[modify] https://crrev.com/8de57ed75f4051d98cb93852c06d744d05cf8989/src/heap/base/asm/arm64/push_registers_asm.cc

Git Watcher via monorail

unread,
Mar 18, 2021, 8:38:05 AM3/18/21
to v8-re...@googlegroups.com

Comment #39 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c39


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/9a97c8630a042dd8c2aefbd76cbecdbac86c0c8e

commit 9a97c8630a042dd8c2aefbd76cbecdbac86c0c8e
Author: Georgia Kouveli <georgia...@arm.com>
Date: Wed Mar 17 10:46:47 2021

[cfi][arm64] Change OSR entry use of LR.

The previous uses of LR here allowed overwriting it with arbitrary addresses
that aren't signed. Change this so we never return to an arbitrary LR.

This makes a difference even when we replace the RET with a BR, because BR is
constrained by BTI, whereas RET isn't.

Bug: v8:10026
Change-Id: Ibbf326ccf0cf32f6d9541c7a82108dc0373827df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767015
Reviewed-by: Georg Neis <ne...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/master@{#73507}

[modify] https://crrev.com/9a97c8630a042dd8c2aefbd76cbecdbac86c0c8e/src/builtins/arm64/builtins-arm64.cc
[modify] https://crrev.com/9a97c8630a042dd8c2aefbd76cbecdbac86c0c8e/src/compiler/backend/arm64/code-generator-arm64.cc

Git Watcher via monorail

unread,
Mar 19, 2021, 7:36:06 AM3/19/21
to v8-re...@googlegroups.com

Comment #40 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c40


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/ce85e66a20813f2714b8cd7b09ce98035f3fcb53

commit ce85e66a20813f2714b8cd7b09ce98035f3fcb53
Author: Georgia Kouveli <georgia...@arm.com>
Date: Thu Mar 18 16:44:37 2021

[cfi][arm64] Change InterpreterEnterBytecode use of LR for CFI.

This use of LR previously allowed overwriting it with arbitrary addresses

that aren't signed. Change this so we never return to an arbitrary LR.

Instead of loading the InterpreterTrampolineEntry address into LR directly,
use an ADR instruction to place into LR the address of a piece of code
that jumps to the InterpreterTrampolineEntry instead. This makes a difference
because BR is also constrained by BTI, whereas RET isn't.

An alternative would have been to `Call` instead of `Jump` to the target
bytecode and avoid the ADR instruction altogether, but I wanted to keep the
same behaviour with respect to the return stack that the existing code
exhibits.

Also add a comment to src/regexp/arm64/regexp-macro-assembler-arm64.cc for
a similar use of LR that should eventually be removed.

Bug: v8:10026
Change-Id: I24a13481f3fa416247dab8f9e5ae6f52f6b2ad42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2764761
Reviewed-by: Ross McIlroy <rmci...@chromium.org>

Reviewed-by: Georg Neis <ne...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>

Git Watcher via monorail

unread,
Aug 5, 2021, 2:18:14 PM8/5/21
to v8-re...@googlegroups.com

Comment #41 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c41


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/948dd6b15a6e269b473051c3b3654aab474abac0

commit 948dd6b15a6e269b473051c3b3654aab474abac0
Author: Adenilson Cavalcanti <adenilson....@arm.com>
Date: Wed Aug 04 17:32:45 2021

[pac][bti] Activate branch protection flag for ARM64

Verify if Chromium's flag was enabled and toggle the flag
for V8, enabling support for PAC (Pointer Authentication Code)
and BTI (Branch Target Identification).

Bug: v8:10026, chromium:1145581, chromium:919548
Change-Id: I7c40674d2f9c8512639a7320b491006697420e28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3072158
Commit-Queue: Martyn Capewell <martyn....@arm.com>
Reviewed-by: Andreas Haas <ah...@chromium.org>
Reviewed-by: Georg Neis <ne...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76126}

[modify] https://crrev.com/948dd6b15a6e269b473051c3b3654aab474abac0/BUILD.gn

Git Watcher via monorail

unread,
Aug 26, 2021, 4:10:07 AM8/26/21
to v8-re...@googlegroups.com

Comment #42 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c42


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/c16c682e3a7d0208c586d0761ab73b683e916873

commit c16c682e3a7d0208c586d0761ab73b683e916873
Author: Lu Yahan <ya...@iscas.ac.cn>
Date: Thu Aug 26 06:01:11 2021

[riscv64][builtins] Clear c_entry_fp when entering JS and at exception path


Port: 07b03b83537dfaee868b7cf42ea4c764981487c3

Bug: v8:10026
Change-Id: I4d7dc0fef98aa1754d3aea1d0f5d13b9bad9d645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118615
Auto-Submit: Yahan Lu <ya...@iscas.ac.cn>
Commit-Queue: Ji Qiu <qi...@iscas.ac.cn>
Reviewed-by: Ji Qiu <qi...@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#76498}

[modify] https://crrev.com/c16c682e3a7d0208c586d0761ab73b683e916873/src/builtins/riscv64/builtins-riscv64.cc

sroet… via monorail

unread,
Mar 25, 2022, 5:30:23 AM3/25/22
to v8-re...@googlegroups.com
Updates:
Cc: sroet...@google.com

Comment #43 on issue 10026 by sroet...@google.com: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c43

(No comment was entered for this change.)

sroet… via monorail

unread,
Mar 25, 2022, 9:59:08 AM3/25/22
to v8-re...@googlegroups.com
Updates:
Cc: andre...@arm.com sa...@chromium.org

Comment #44 on issue 10026 by sroet...@google.com: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c44

Continuing the discussion from the https://chromium-review.googlesource.com/c/v8/v8/+/3548457 here:

From Andre:
> we discussed the issue with the V8 team here at Arm (I am more involved with Chromium). We have this one on PAC and BTI in V8, see https://docs.google.com/document/d/1U13TcWthAXR0BDkI4TmgGlQmuKrX4Ptp0C7ob-PlO8A/edit#heading=h.s6qmr4ktilv7
>
> Furthermore, we have some general documentation on PAC, BTI and the type of attacks they prevent, see https://developer.arm.com/documentation/102433/latest/ .
>
> Is that what you are looking for?

That's a very good start, thank you! I was wondering if there was a discussion about the threat model for v8 in particular. I.e. one large challenge we have regarding memory corruption mitigations is that the JIT compiler will generate machine code in a writable mapping, which another thread can write to in parallel.
It sounds like we should try to solve this problem so that the PAC changes can be effective. Did you already chat about this internally?

Git Watcher via monorail

unread,
Mar 25, 2022, 12:29:10 PM3/25/22
to v8-re...@googlegroups.com

Comment #45 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c45


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/c482a66bd784f536d7d711e390312c9e0ee5dc05

commit c482a66bd784f536d7d711e390312c9e0ee5dc05
Author: André Kempe <andre...@arm.com>
Date: Fri Mar 18 14:24:29 2022

Enable PAC and BTI for runtime generated code.

This patch enables PAC and BTI for runtime generated code when PAC
is enabled. Additional BTI landing pads will resolve to NOOP when
running on non BTI device and will not cause functional problems.

Change-Id: I3993481df2c3c47e3e81bfb76a8c355f642cd572
Bug: chromium:919548, v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548457
Reviewed-by: Leszek Swirski <les...@chromium.org>
Commit-Queue: Andre Kempe <andre...@arm.com>
Cr-Commit-Position: refs/heads/main@{#79630}

[modify] https://crrev.com/c482a66bd784f536d7d711e390312c9e0ee5dc05/BUILD.gn

Git Watcher via monorail

unread,
Mar 28, 2022, 8:07:11 PM3/28/22
to v8-re...@googlegroups.com

Comment #46 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c46


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/7e28b58cd7d53a550c8dbb9885abf995d84fcf31

commit 7e28b58cd7d53a550c8dbb9885abf995d84fcf31
Author: Adam Klein <ad...@chromium.org>
Date: Mon Mar 28 23:21:44 2022

Revert "Enable PAC and BTI for runtime generated code."

This reverts commit c482a66bd784f536d7d711e390312c9e0ee5dc05.

Reason for revert: causes crashes in ChromeOS/MSAN builds:
https://crbug.com/1310642

Original change's description:

> Enable PAC and BTI for runtime generated code.
>
> This patch enables PAC and BTI for runtime generated code when PAC
> is enabled. Additional BTI landing pads will resolve to NOOP when
> running on non BTI device and will not cause functional problems.
>
> Change-Id: I3993481df2c3c47e3e81bfb76a8c355f642cd572
> Bug: chromium:919548, v8:10026
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548457
> Reviewed-by: Leszek Swirski <les...@chromium.org>
> Commit-Queue: Andre Kempe <andre...@arm.com>
> Cr-Commit-Position: refs/heads/main@{#79630}

Bug: chromium:919548, v8:10026, chromium:1310642
Change-Id: I564efa5327ae038a7b5fb69b416300afebe2cd74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3556706
Bot-Commit: Rubber Stamper <rubber-...@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <ad...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79644}

[modify] https://crrev.com/7e28b58cd7d53a550c8dbb9885abf995d84fcf31/BUILD.gn

richa… via monorail

unread,
Apr 1, 2022, 8:53:29 AM4/1/22
to v8-re...@googlegroups.com
Updates:
Blocking: chromium:919548

Comment #47 on issue 10026 by richa...@arm.com: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c47

Hi, so me, André and V8 team internally at Arm have been talking about the threat model WRT to re-landing the above. The context is that we've switched on PAC for the C++ parts of Chromium and V8 in in M101 (see [2] for more details on that). The attack scenario I'm thinking about goes something like this:

1. An attacker finds a stack-relative OOB write in some C++ (e.g. in Blink's layout code).
2. The attacker uses this OOB to overwrite the local return address and launch a ROP chain.

In M101, attacks like this become much more difficult because pointer authentication detects the modification. However, the attacker can still exploit any stack frames that aren't protected, i.e.:

1. Attacker finds the OOB write
2. The attacker knows that this OOB happens 12 stack frames below a V8 JIT-compiled frame
3. Attacker computes the return address of the V8 frame, overwrites it, starts a ROP-chain from V8.

This approach will also work for Android system libraries and Android Runtime-generated code (which is why we're currently trying to add PAC everywhere we possibly can).

With regard to V8 specifically, PAC doesn't help with RWX and is still vulnerable to a class of pointer substitution attacks (Georgia can give you access to this doc [1] for more on that). But I think that enabling it for V8 is still important to better protect the C++.

[1] https://docs.google.com/document/d/1jvuWtKCc_XemqFMXyCtbezLye2iR7-jSamw_Po5BvGI/edit
[2] https://docs.google.com/document/d/1mmXakwgqUXB8nHvCrk6q3Ek2kg8z9z1-rnram6Rp9Rs/edit#heading=h.x2dpj75yurk1

Git Watcher via monorail

unread,
Apr 8, 2022, 8:54:22 AM4/8/22
to v8-re...@googlegroups.com

Comment #48 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c48


The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/6a413927185bc8ec68cbbf8f8a0cd3c75aae4a02

commit 6a413927185bc8ec68cbbf8f8a0cd3c75aae4a02
Author: Richard Townsend <Richard.Townsend@arm.com>
Date: Fri Apr 08 12:53:31 2022

fix: flag inconsistency for cross-arch builds

In the ChromeOS MSAN configuration, the V8 simulator
(implying v8_target_cpu="arm64") is used to catch memory safety errors.
This is not a supported configuration for pointer authentication.

Bug: v8:10026, 919548
Change-Id: I8f68243460ba0327b9978098c81cf29060175d12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3571780
Reviewed-by: Andrew Grieve <agr...@chromium.org>
Commit-Queue: Richard Townsend <richard....@arm.com>
Cr-Commit-Position: refs/heads/main@{#990353}

[modify] https://crrev.com/6a413927185bc8ec68cbbf8f8a0cd3c75aae4a02/build/config/arm.gni

Git Watcher via monorail

unread,
Apr 8, 2022, 11:35:10 AM4/8/22
to v8-re...@googlegroups.com

Comment #49 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c49


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/ed8e8b949a92f7c35a10fd44f065b3b7b1834f5a

commit ed8e8b949a92f7c35a10fd44f065b3b7b1834f5a
Author: André Kempe <andre...@arm.com>
Date: Fri Mar 18 14:24:29 2022

Reland "Enable PAC and BTI for runtime generated code."

This is a reland of commit c482a66bd784f536d7d711e390312c9e0ee5dc05


Original change's description:
> Enable PAC and BTI for runtime generated code.
>
> This patch enables PAC and BTI for runtime generated code when PAC
> is enabled. Additional BTI landing pads will resolve to NOOP when
> running on non BTI device and will not cause functional problems.
>
> Change-Id: I3993481df2c3c47e3e81bfb76a8c355f642cd572
> Bug: chromium:919548, v8:10026
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548457
> Reviewed-by: Leszek Swirski <les...@chromium.org>
> Commit-Queue: Andre Kempe <andre...@arm.com>
> Cr-Commit-Position: refs/heads/main@{#79630}

Bug: chromium:919548, chromium:1310642, v8:10026
Change-Id: I5f76705a222b5f4fbc07cf472c02e9b58b5171fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579164

Reviewed-by: Leszek Swirski <les...@chromium.org>
Commit-Queue: Andre Kempe <andre...@arm.com>
Cr-Commit-Position: refs/heads/main@{#79895}

[modify] https://crrev.com/ed8e8b949a92f7c35a10fd44f065b3b7b1834f5a/BUILD.gn

Git Watcher via monorail

unread,
Jun 7, 2022, 12:14:35 PM6/7/22
to v8-re...@googlegroups.com

Comment #50 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c50


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/2ed27bba6a881a152887f3ab1008e989fce617e3

commit 2ed27bba6a881a152887f3ab1008e989fce617e3
Author: Georgia Kouveli <georgia...@arm.com>
Date: Tue Jun 07 14:23:11 2022

[arm64] Fix GCC build issue for CFI

GCC doesn't accept 'lr' in inline assembly, specifically for the
list of clobbered registers. Change all uses to 'x30', for
consistency.

Bug: v8:10026
Change-Id: I5654fee4ca398dfdd99c34d09fc5294d169a9bd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693701
Reviewed-by: Igor Sheludko <ish...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/main@{#80980}

[modify] https://crrev.com/2ed27bba6a881a152887f3ab1008e989fce617e3/src/execution/arm64/pointer-authentication-arm64.h

Git Watcher via monorail

unread,
Jun 9, 2022, 1:30:07 PM6/9/22
to v8-re...@googlegroups.com

Comment #51 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c51


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/fb235844dc44d6beb90bf59a1298ff41c4d58fcf

commit fb235844dc44d6beb90bf59a1298ff41c4d58fcf
Author: Georgia Kouveli <georgia...@arm.com>
Date: Wed Jun 08 10:34:56 2022

[arm64] Fix CFI issue with short builtin calls

The allowlist used for `Deoptimizer::IsValidReturnAddress` depends on
fixed embedded builtin addresses. Pass a pointer to the isolate to
this method, so that it can discover the actual builtin code start
(which may have been remapped) and calculate the offset from the start
of the builtins' code in order to check if the return address is
allowed.

After this change, do not disable short builtin calls when CFI is
enabled.

There's an important TODO for this change:
Since the builtin code pointer that's used to check whether a return
address is allowed is now writable, we should use pointer authentication
to protect it.

Bug: v8:10026
Change-Id: Iafd31d3ad7e10cb17faf33e76e78d3df36edeefd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667506
Reviewed-by: Toon Verwaest <verw...@chromium.org>

Reviewed-by: Igor Sheludko <ish...@chromium.org>
Commit-Queue: Georgia Kouveli <georgia...@arm.com>
Cr-Commit-Position: refs/heads/main@{#81049}

[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/deoptimizer-cfi-builtins.cc
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/deoptimizer-cfi-empty.cc
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/frame-description.h
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/arm64/deoptimizer-arm64.cc
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/deoptimizer.h
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/execution/arm64/pointer-authentication-arm64.h
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/BUILD.gn
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/deoptimizer/deoptimizer.cc
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/execution/pointer-authentication-dummy.h
[modify] https://crrev.com/fb235844dc44d6beb90bf59a1298ff41c4d58fcf/src/execution/pointer-authentication.h

Git Watcher via monorail

unread,
Sep 27, 2022, 12:16:09 PM9/27/22
to v8-re...@googlegroups.com

Comment #53 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c53


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/aee072cbc3ef65278c4b0db9bdfe0e114a5e5ee5

commit aee072cbc3ef65278c4b0db9bdfe0e114a5e5ee5
Author: Pierre Langlois <pierre....@arm.com>
Date: Tue Sep 13 17:21:25 2022

[arm64] Enable CFI by default on Android and Linux.

The `v8_control_flow_integrity` build flag was already on by default in
Chromium on those platforms, by depending on
`arm_control_flow_integrity`. We should also turn it on by default when
building V8 standalone.

Co-authored-by: Richard Townsend <richard....@arm.com>

Bug: v8:10026, v8:12963
Change-Id: I361a6426f44e569c08c763cf84a687ca70b89f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829068
Reviewed-by: Michael Achenbach <mache...@chromium.org>
Reviewed-by: Igor Sheludko <ish...@chromium.org>
Commit-Queue: Pierre Langlois <pierre....@arm.com>
Cr-Commit-Position: refs/heads/main@{#83458}

[modify] https://crrev.com/aee072cbc3ef65278c4b0db9bdfe0e114a5e5ee5/BUILD.gn

Git Watcher via monorail

unread,
Mar 29, 2023, 2:57:13 PM3/29/23
to v8-re...@googlegroups.com

Comment #54 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c54


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/f0e1ca1449e03d55f6a1aacfe93933aa0c5b3157

commit f0e1ca1449e03d55f6a1aacfe93933aa0c5b3157
Author: Pierre Langlois <pierre....@arm.com>
Date: Wed Mar 29 14:28:27 2023

[arm64][cfi] Use xpaclri instruction to check authentication status

The AuthenticatePC() and ReplacePC() pointer-authentication utilities
are written so that they should cause a crash in case the authentication
fails. We use the `autib1716` instruction to do the authentication,
however this instruction isn't guaranteed to cause a crash. Instead, it
may yield an invalid pointer which is then guaranteed to cause a crash
on use.

To ensure that we crash as soon as possible in the case of a failed
authentication, we have a load instruction on the result:

;; Place result in x17.
autib1716
;; Ensure that x17 can be dereferenced.
ldr xzr, [x17]

However, this approach does not always work, for two reasons:

- The address at `x17` may not be dereferenceable. This can happen
when using ReplacePC(), which ensures that the previous address is
correctly authenticated before replacing it. However the GC may have
reclaimed the memory the previous address points to.

- The `ldr` instruction is a *data* load, while the address at `x17`
is an instruction address. The specification only guarantees that
`autib1716` generates an invalid *instruction* pointer, and the only
way to ensure it is valid is to use it via a call instruction, not a
data load.

This can happen if TBI (top-byte-ignore) is disabled for instruction
addresses but enabled on data addresses. In this case, a failed
authentication of an instruction address will be indicated by a bit
set in the TBI range. It then will *not* cause a crash when used
with `ldr`, as it's a *data* load subject to TBI.

To fix this, this CL uses an alternative sequence to check if the
authentication is successful, by using the `xpaclri` instruction.

Bug: v8:10026
Change-Id: Ie1e4bff380fca226beb29d3dfe27e48d87ec736c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4381728
Commit-Queue: Pierre Langlois <pierre....@arm.com>
Reviewed-by: Igor Sheludko <ish...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86782}

[modify] https://crrev.com/f0e1ca1449e03d55f6a1aacfe93933aa0c5b3157/test/unittests/BUILD.gn
[add] https://crrev.com/f0e1ca1449e03d55f6a1aacfe93933aa0c5b3157/test/unittests/execution/pointer-auth-arm64-unittest.cc
[modify] https://crrev.com/f0e1ca1449e03d55f6a1aacfe93933aa0c5b3157/src/execution/arm64/pointer-authentication-arm64.h
[delete] https://crrev.com/4f94782e87a227072295dde051c50634af3eda05/test/unittests/codegen/pointer-auth-arm64-unittest.cc

Git Watcher via monorail

unread,
Mar 18, 2024, 6:43:25 AM3/18/24
to v8-re...@googlegroups.com

Comment #55 on issue 10026 by Git Watcher: CFI measures for arm64
https://bugs.chromium.org/p/v8/issues/detail?id=10026#c55


The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8/+/595cbca0a38fa9476fc6832c87d881edf16de7e6

commit 595cbca0a38fa9476fc6832c87d881edf16de7e6
Author: Pierre Langlois <pierre....@arm.com>
Date: Fri Mar 15 18:06:43 2024

[arm64][cfi] Add "cc" to clobber list in authentication inline asm

When authenticating in inline assembly, we do a comparison to check if
the authentication was successful. This means we write to the
PSTATE.NZCV flags and so need to tell the compiler it cannot insert this
assembly between a comparison and a branch.

Add "cc" to the clobber list to fix this.

As a quick cleanup, add a comment clarifying why LR is restored, as it's
not obvious.

Bug: v8:10026
Change-Id: I62ad7bab72cb686cde71be9d657942c7930b86a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5372731
Auto-Submit: Pierre Langlois <pierre....@arm.com>
Commit-Queue: Igor Sheludko <ish...@chromium.org>
Reviewed-by: Igor Sheludko <ish...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92869}

[modify] https://crrev.com/595cbca0a38fa9476fc6832c87d881edf16de7e6/src/execution/arm64/pointer-authentication-arm64.h
Reply all
Reply to author
Forward
0 new messages