Introduce aarch64-unknown-linux-pauthtest target

[jchlanda]

View all comments

This target enables Pointer Authentication Code (PAC) support in Rust on AArch64
ELF-based Linux systems. It uses the aarch64-unknown-linux-pauthtest LLVM
target and a pointer-authentication-enabled sysroot with a custom musl as a
reference libc implementation. Dynamic linking is required, with a dynamic
linker acting as the ELF interpreter that can resolve pauth relocations and
enforce pointer authentication constraints.

Supported features include:

• authentication of signed function pointers for extern "C" calls (corresponds
  to LLVM's -fptrauth-calls)
• signing of return addresses before spilling to the stack and authentication
  after restoring for non-leaf functions (corresponds to -fptrauth-returns)
• trapping on authentication failure when the FPAC feature is not present
  (corresponds to -fptrauth-auth-traps)
• signing of init/fini array entries using the LLVM-defined pointer
  authentication scheme (corresponds to -fptrauth-init-fini and
  -fptrauth-init-fini-address-discrimination)
• non-ABI-affecting indirect control-flow hardening features as implemented in
  LLVM (corresponds to -faarch64-jump-table-hardening and
  -fptrauth-indirect-gotos)
• signed ELF GOT entries (gated behind -Z ptrauth-elf-got, off by default)

Existing compiler support, such as enabling branch authentication instructions
(i.e.: -Z branch-protection) provide limited functionality, mainly signing
return addresses (pac-ret). The new target goes further by enabling ABI-level
pointer authentication support.

This target does not define a new ABI; it builds on the existing C/C++ language
ABI with pointer authentication support added. However, different authentication
features, encoded in the signing schema, are not ABI-compatible with one
another.

Useful links:

• Earlier PR: [WIP] Introduce aarch64-unknown-linux-pauthtest target #154759
• Part of: Add support for AArch64 Pointer Authentication ABI in Rust #148640
• Project goal: https://rust-lang.github.io/rust-project-goals/2026/aarch64_pointer_authentication_pauthtest.html
• Clang pointer authentication documentation:
  https://clang.llvm.org/docs/PointerAuthentication.html
• LLVM pointer authentication documentation:
  https://llvm.org/docs/PointerAuth.html
• PAuth ABI Extension to ELF for the AArch64 architecture:
  https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst

Tier 3 check list

• A tier 3 target must have a designated developer or developers (the "target
  maintainers") on record to be CCed when issues arise regarding the target.
  (The mechanism to track and CC such developers may evolve over time.)

I pledge to do my best maintaining it.

• Targets must use naming consistent with any existing targets; for instance, a
  target for the same CPU or OS as an existing Rust target should use the same
  name for that CPU or OS. Targets should normally use the same names and
  naming conventions as used elsewhere in the broader ecosystem beyond Rust
  (such as in other toolchains), unless they have a very good reason to
  diverge. Changing the name of a target can be highly disruptive, especially
  once the target reaches a higher tier, so getting the name right is important
  even for a tier 3 target.

The name chosen for the target is aarch64-unknown-linux-pauthtest which
mirrors the LLVM target naming.

• Target names should not introduce undue confusion or ambiguity unless
  absolutely necessary to maintain ecosystem compatibility. For example, if
  the name of the target makes people extremely likely to form incorrect
  beliefs about what it targets, the name should be changed or augmented to
  disambiguate it.

There should be no confusion, the name follows naming convention and is
descriptive.

• If possible, use only letters, numbers, dashes and underscores for the name.
  Periods (.) are known to cause issues in Cargo.

Letters, numbers and dashes only.

• Tier 3 targets may have unusual requirements to build or use, but must not
  create legal issues or impose onerous legal terms for the Rust project or for
  Rust developers or users.

The target requires system clang and lld available as well as custom libc
(musl based) and sysroot, provided through the build scripts.

• The target must not introduce license incompatibilities.

There are no license implications.

• Anything added to the Rust repository must be under the standard Rust
  license (MIT OR Apache-2.0).

Understood.

• The target must not cause the Rust tools or libraries built for any other
  host (even when supporting cross-compilation to the target) to depend
  on any new dependency less permissive than the Rust licensing policy. This
  applies whether the dependency is a Rust crate that would require adding
  new license exceptions (as specified by the tidy tool in the
  rust-lang/rust repository), or whether the dependency is a native library
  or binary. In other words, the introduction of the target must not cause a
  user installing or running a version of Rust or the Rust tools to be
  subject to any new license requirements.

There are no new dependencies or requirements.

• Compiling, linking, and emitting functional binaries, libraries, or other
  code for the target (whether hosted on the target itself or cross-compiling
  from another target) must not depend on proprietary (non-FOSS) libraries.
  Host tools built for the target itself may depend on the ordinary runtime
  libraries supplied by the platform and commonly used by other applications
  built for the target, but those libraries must not be required for code
  generation for the target; cross-compilation to the target must not require
  such libraries at all. For instance, rustc built for the target may
  depend on a common proprietary C runtime library or console output library,
  but must not depend on a proprietary code generation library or code
  optimization library. Rust's license permits such combinations, but the
  Rust project has no interest in maintaining such combinations within the
  scope of Rust itself, even at tier 3.

The target only relies on open source tools.

• "onerous" here is an intentionally subjective term. At a minimum, "onerous"
  legal/licensing terms include but are not limited to: non-disclosure
  requirements, non-compete requirements, contributor license agreements
  (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
  requirements conditional on the employer or employment of any particular
  Rust developers, revocable terms, any requirements that create liability
  for the Rust project or its developers or users, or any requirements that
  adversely affect the livelihood or prospects of the Rust project or its
  developers or users.

No such terms present.

• Neither this policy nor any decisions made regarding targets shall create any
  binding agreement or estoppel by any party. If any member of an approving
  Rust team serves as one of the maintainers of a target, or has any legal or
  employment requirement (explicit or implicit) that might affect their
  decisions regarding a target, they must recuse themselves from any approval
  decisions regarding the target's tier status, though they may otherwise
  participate in discussions.

Understood.

• This requirement does not prevent part or all of this policy from being
  cited in an explicit contract or work agreement (e.g. to implement or
  maintain support for a target). This requirement exists to ensure that a
  developer or team responsible for reviewing and approving a target does not
  face any legal threats or obligations that would prevent them from freely
  exercising their judgment in such approval, even if such judgment involves
  subjective matters or goes beyond the letter of these requirements.

Understood.

• Tier 3 targets should attempt to implement as much of the standard libraries
  as possible and appropriate (core for most targets, alloc for targets
  that can support dynamic memory allocation, std for targets with an
  operating system or equivalent layer of system-provided functionality), but
  may leave some code unimplemented (either unavailable or stubbed out as
  appropriate), whether because the target makes it impossible to implement or
  challenging to implement. The authors of pull requests are not obligated to
  avoid calling any portions of the standard library on the basis of a tier 3
  target not implementing those portions.

aarch64-unknown-linux-pauthtest target has std library support, moreover all
library tests pass for the target.

• The target must provide documentation for the Rust community explaining how
  to build for the target, using cross-compilation if possible. If the target
  supports running binaries, or running tests (even if they do not pass), the
  documentation must explain how to run such binaries or tests for the target,
  using emulation if possible or dedicated hardware if necessary.

Platform support document covers building instructions.

• Tier 3 targets must not impose burden on the authors of pull requests, or
  other developers in the community, to maintain the target. In particular,
  do not post comments (automated or manual) on a PR that derail or suggest a
  block on the PR based on a tier 3 target. Do not send automated messages or
  notifications (via any medium, including via @) to a PR author or others
  involved with a PR regarding a tier 3 target, unless they have opted into
  such messages.

Understood.

• Backlinks such as those generated by the issue/PR tracker when linking to
  an issue or PR are not considered a violation of this policy, within
  reason. However, such messages (even on a separate repository) must not
  generate notifications to anyone involved with a PR who has not requested
  such notifications.

Understood.

• Patches adding or updating tier 3 targets must not break any existing tier 2
  or tier 1 target, and must not knowingly break another tier 3 target without
  approval of either the compiler team or the maintainers of the other tier 3
  target.

Understood.

• In particular, this may come up when working on closely related targets,
  such as variations of the same architecture with different features. Avoid
  introducing unconditional uses of features that another variation of the
  target may not have; use conditional compilation or runtime detection, as
  appropriate, to let each target run code supported by that target.

Understood.

• Tier 3 targets must be able to produce assembly using at least one of
  rustc's supported backends from any host target. (Having support in a fork
  of the backend is not sufficient, it must be upstream.)

It is expected that the target should be able to compile binaries on any systems
that are capable of compiling aarch64 code.

[jchlanda]

For a full context I'm going to bring comments from a draft PR into this one:

@tgross35
Could pauth-quicksort-*-driver be combined into one run-make test that builds/runs two different things in main? Since they can probably share some docs or reuse some code, and it saves the per-test overhead.

View changes since the review

[jchlanda]

@tgross35, not without some serious code juggling; conceptually those two tests perform identical tasks. However, the problem is that pauth-quicksort-c-driver creates a C executable that links against a Rust library. While pauth-quicksort-rust-driver does the opposite, creating a Rust executable that is linked against a C library.

I could put all the sources in one directory and handle compilations from one build script, but am not sure if that would make for a clear, easy to follow test?

[jchlanda]

r? compiler

[jchlanda]

cc: @davidtwco

[madsmtm]

I tend to think this should set target_abi = "pauth" instead of target_env = "pauth"? Or maybe an entirely new cfg(target_has_pointer_authentication)?

My motivation is that arm64e Apple targets have pointer authentication as well, but there target_env is used for things like Mac Catalyst too (target_env = "macabi").

View changes since the review

[jchlanda]

Target triple, aarch64-unknown-linux-pauthtest, mimics exactly what LLVM defines. With pauthtest being llvm::Triple::EnvironmentType.

What I don't like about explicitly using target_abi is that it might set an incorrect expectation. While it is true, that different authentication features, encoded in the signing schema, are not ABI-compatible with one another, pauthtest is not a new ABI, it follows C/C++ language ABI, with pointer authentication features. Also, while LLVM allows for -mabi=pauthtest (i.e.: calng --target=aarch64-linux -mabi=pauthtest) it is then normalized to environment part of the triple effective re-creating aarch64-unknown-linux-pauthtest.

WRT other targets supporting pointer authentication features. I have a follow up task to abstract that away. Clang handles it gracefully, where platform/environment is normalized to a set of language features, that are then used to create a concrete signing schema.

[madsmtm]

What I don't like about explicitly using target_abi is that it might set an incorrect expectation. While it is true, that different authentication features, encoded in the signing schema, are not ABI-compatible with one another, pauthtest is not a new ABI, it follows C/C++ language ABI, with pointer authentication features.

That still feels like it can fit under the definition of "new ABI" IMO? At least if you take the view "if it's not compatible, it's a new ABI".

Anyhow, my primary argument here comes after reading the libc PR, it feels like being able to set target_env = "musl" would make things a lot simpler in most user code?

EDIT: I see now that you've also discussed that with @tgross35.

(If we do that, I'd probably lean towards this target being called aarch64-unknown-linux-muslpauth and it setting target_env = "musl" and target_abi = "pauth", because that would make cc-rs' parsing easier too).

[asl]

Currently musl is just an implementation detail and we do not want to set this in the stone. It is just a reference proof-of-concept libc implementation that was done on top of musl in the downstream patch, however, this does not imply that:

• Upstream musl will support pauth anytime soon (and frankly speaking, the real-world implementation should be done a bit differently to ensure e.g. there are no exploitable signing oracles)
• There might be other standard libraries supporting pauth (I am thinking about bare-metal world here mostly)
• Still, some requirements would likely hold for any standard library implementations (e.g. while static link is in theory possible, in reality it would require lots of weird things especially when address discrimination is involved).

To add more on top of it – we're currently discussing ways how we can modify pauthtest approach in Clang/LLVM. So the target triple with environment is an interim solution (this was the motivation of test in the name) that will go away but for now we'd need it in some form :)

[davidtwco]

My gut instincts with regards to the target name match @madsmtm's. It's relatively easy for us to change, remove or add new targets with different triples for other standard libraries or environments, so we can make this target as descriptive as possible for the environment is corresponds to.

[tgross35]

From a libs perspective I'd rather have target_env = "musl" as well if that tells us the API we are allowed to use. Otherwise this target is always going to be playing catch up when something gets gated on target_env = "musl" but doesn't account for pauthtest. I also don't know that we need to mirror LLVM if we could do something that's an improvement. (It's fine IMO to not say "musl" in the target triple but still specify that in the env, if that's one of the concerns.)

Perhaps worth a Zulip thread?

[jchlanda]

Perhaps worth a Zulip thread?

https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.60aarch64-unknown-linux-pauthtest.60

[madsmtm]

I feel like the motivation for having "test" in the name is somewhat weak? If the intention is that the target is unstable, we have better ways of enforcing that (such as a check that you're on the nightly channel before using the target).

View changes since the review

[jchlanda]

pauthtest mimics what LLVM uses: llvm::Triple::EnvironmentType.

[madsmtm]

Yeah, I understand that, but I'm not convinced we should carry that forwards? Do you have a link to the original motivation for that name in LLVM?

I guess it depends on how widely you expect to see usage of this target? If there's any point where libraries are going to do target_env = "pauthtest", where it would need to be updated to target_env = "pauth" or smth in the future, then I think it's a bad idea?

[jchlanda]

There is an ongoing discussion as to how to move forward with the naming on the LLVM side (see the round table report). My preference would be to stick with pauthtest and wait for LLVM to come up with their new name, which I'll be happy to adopt here.

[JohnTitor]

r? madsmtm

[rustbot]

madsmtm is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

This PR modifies tests/auxiliary/minicore.rs.

cc @jieyouxu

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

These commits modify compiler targets.
(See the Target Tier Policy.)

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Some changes occurred in std_detect

cc @Amanieu, @folkertdev, @sayantn

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[davidtwco]

@bors r+

[rust-bors]

📌 Commit 52ccc75 has been approved by davidtwco

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1. This pull request will be tested once the tree is reopened.