-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[AArch64] When signing return addresses by default, using some Concurrency primitives can cause a crash #80059
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
triage needed
This issue needs more specific labels
Comments
This is mainly of relevance to the OpenBSD port but is not limited to it. |
3405691582
added a commit
to 3405691582/swift
that referenced
this issue
Mar 28, 2025
To work-around swiftlang#80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option. We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults off for now. Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
3405691582
added a commit
to 3405691582/swift-driver
that referenced
this issue
Mar 28, 2025
On the swift side, we added a new build flavor in swiftlang/swift#xxxxx to opt-out of BTCFI as a way of working around swiftlang/swift#80059. We communicate this to swift-driver via the frontend with FrontendTargetInfo.
3405691582
added a commit
to 3405691582/swift-driver
that referenced
this issue
Mar 28, 2025
On the swift side, we added a new build flavor in swiftlang/swift#xxxxx to opt-out of BTCFI as a way of working around swiftlang/swift#80059. We communicate this to swift-driver via the frontend with FrontendTargetInfo.
3405691582
added a commit
to 3405691582/swift
that referenced
this issue
Mar 28, 2025
To work-around swiftlang#80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option. We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults off for now. Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
3405691582
added a commit
to 3405691582/swift
that referenced
this issue
Mar 29, 2025
To work-around swiftlang#80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option. We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults to off for now. Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
3405691582
added a commit
to 3405691582/swift
that referenced
this issue
Mar 29, 2025
To work-around swiftlang#80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option. We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults to off for now. Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
3405691582
added a commit
to 3405691582/swift
that referenced
this issue
Mar 29, 2025
To work-around swiftlang#80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option. We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults to off for now. Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
3405691582
added a commit
to 3405691582/swift-driver
that referenced
this issue
Mar 29, 2025
On the swift side, we added a new build flavor in swiftlang/swift#80389 to opt-out of BTCFI as a way of working around swiftlang/swift#80059. We communicate this to swift-driver via the frontend with FrontendTargetInfo.
3405691582
added a commit
to 3405691582/swift-driver
that referenced
this issue
Apr 19, 2025
On the swift side, we added a new build flavor in swiftlang/swift#80389 to opt-out of BTCFI as a way of working around swiftlang/swift#80059. We communicate this to swift-driver via the frontend with FrontendTargetInfo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
triage needed
This issue needs more specific labels
Description
Using
-msign-return-address
options (like in #78394 on OpenBSD) and Concurrency primitives likewithTaskGroup
can cause a PAC trap.The hypothesis is that Concurrency may perform some manipulations for task switching that would otherwise require manual pointer signing, but the intrinsics for manual pointer signing in LLVM are gated on Darwin, so manual signing does not occur. This conflicts with the enabled return address/stack pointer signing.
Reproduction
Execute with
swiftc -parse-as-library -g bad.swift -Xcc -Xclang=-msign-return-address=non-leaf
.Expected behavior
Code executes normally.
Environment
aarch64: swift 6.0.3 prebuilt on Linux, swift HEAD on OpenBSD.
Additional information
As mentioned, manual pointer signing is available on Darwin/aarch64, so this doesn't actually pose a problem there.
However, we use
-msign-return-address
on OpenBSD since enforcement of indirect branch targets is mandatory, unless explicitly opted out by informing the platform linker (with-z nobtcfi
). The platform compiler adds the flags-mbranch-target-enforce
,-msign-return-address=non-leaf
, and-msign-return-address-key=a_key
by default. When the latter two options are enabled, the compiler emitspaciasp
andautiasp
instructions for PAC on the stack pointer. When there is a misbranch on OpenBSD, the binary will receive a SIGILL signal and codeILL_BTCFI
to indicate this branch target issue. However, in the above case, the ESR indicates a pointer authentication failure.-msign-return-address
appears optional on Linux, though enabling it highlights the problem as well.The text was updated successfully, but these errors were encountered: