[WIP] Introduce aarch64-unknown-linux-pauthtest target by jchlanda · Pull Request #154759 · rust-lang/rust

jchlanda · 2026-04-03T15:20:23Z

The target enables Pointer Authentication Code (PAC) support in Rust on AArch64
ELF based Linux systems using a pauthtest ABI (provided by LLVM) and
pauthtest-enabled sysroot with custom musl, serving as a reference libc
implementation. It requires dynamic linking with a pauthtest-enabled dynamic
linker serving as ELF interpreter capable of resolving pauth relocations and
respecting pauthtest ABI constraints.

Supported features include:

authenticating signed function pointers for extern "C" function calls
(corresponds to -fptrauth-calls included in pauthtest ABI as defined in
LLVM)
signing return address before spilling to stack and authenticating return
address after restoring from stack for non-leaf functions (corresponds to
-fptrauth-returns)
trapping if authentication failure is detected and FPAC feature is not present
(corresponds to -fptrauth-auth-traps)
signing of init/fini array entries with the signing schema used for pauthtest
ABI (corresponding to -fptrauth-init-fini,
-fptrauth-init-fini-address-discrimination)
non-ABI-affecting indirect control flow hardening features included in
pauthtest ABI (corresponding to -faarch64-jump-table-hardening,
-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.

Please note that efforts were made to split the work into individual commits
that encapsulate different areas of the code; however, the commits are not
atomic and cannot be built or tested in isolation.

Useful links:

project goal
issue describing the need for the work: Add support for AArch64 Pointer Authentication ABI in Rust #148640

kovdan01 · 2026-04-15T22:35:00Z

+                // authentication features is currently supported. By default, the absence of this
+                // info is treated as compatible with any binary.
+                //
+                // Please note, that this would cause compatibility issues when linking against


// (for example member function pointers, virtual function pointers, virtual table // pointers).

Probably "for example, signing of C++ member ..."

asl · 2026-04-15T22:46:50Z

+
+#[inline]
+pub(crate) fn pauth_fn_attrs() -> &'static [&'static str] {
+    // FIXME(jchlanda) This is not an exhaustive list of all `pauthtest`-related attributes, but


Suggested change

// FIXME(jchlanda) This is not an exhaustive list of all `pauthtest`-related attributes, but

// FIXME(jchlanda) This is not an exhaustive list of all `ptrauth`-related attributes, but

View changes since the review

asl · 2026-04-15T22:48:30Z

        let address_space = cx.tcx.global_alloc(prov.alloc_id()).address_space(cx);
-
-        llvals.push(cx.scalar_to_backend(
+        // For aarch64-unknown-linux-pauthtest function pointers stored in init/fini arrays need


I'd rather say something like "Under pointer authentication function pointers stored in init/fini arrays need special handling"

View changes since the review

kovdan01

@asl I would appreciate if you could continue review so we can get the internal review phase done in this PR sooner than later and re-submit it as a new clean PR.

As for my comments, I consider them mostly fixed, but I'd like a second pair of eyes to have a look at the changes

View changes since this review

kovdan01 · 2026-04-17T12:15:46Z

+* UI error reporting (pauthtest does not support `+crt-static`)
+  * crt-static-pauthtest.rs
+
+All tests from `assembly-llvm`, `codegen-llvm`, `codegen-units`, `coverage`,


Maybe worth adding in the textual explanation as well? Looks like it's now only present in the invocation command

`const_ptr_auth` wraps aroudn `LLVMRustConstPtrAuth`, which provides a way to decorate a function pointer in `ConstPtrAuth`.

Allow PAC metadata to be passed to `get_fn_addr` and related API changes.

The set of supported attributes is: function * "aarch64-jump-table-hardening" * "ptrauth-auth-traps" * "ptrauth-calls" * "ptrauth-indirect-gotos" * "ptrauth-returns" module * "ptrauth-elf-got" * "ptrauth-sign-personality"

Also add flag for ELF-GOT signing.

Also: * update tests to force dynamic library when targetting pauthtest * various test fixes * introduce end-to-end tests for pauthtest (in run-make)

asl

See comments on misleading (IMO) use of pauthtest

View changes since this review

asl · 2026-04-20T23:21:49Z

            {
-                let attrs = attributes::sanitize_attrs(&cx, tcx, SanitizerFnAttrs::default());
+                let mut attrs = attributes::sanitize_attrs(&cx, tcx, SanitizerFnAttrs::default());
+                // For pauthtest make sure that the ptrauth-* attributes are also attached to the


This is not pauthtest-specific. This is generic pointer authentication code. I would rephrase the comment

asl · 2026-04-20T23:22:33Z

+        if self.sess().target.env != Env::Pauthtest {
+            return None;
+        }
+        // Pauthtest only supports extern "C" calls, filter out other ABIs.


Should be generic pointer authentication

asl · 2026-04-20T23:23:07Z


+#[derive(Diagnostic)]
+#[diag(
+    "pauthtest ABI is incompatible with statically linked libc, disable it using `-C target-feature=-crt-static`"


It is not ABI.

asl · 2026-04-20T23:23:26Z

+pub(crate) struct CannotEnableCrtStaticPauthtest;
+


I would not use Pauthtest in the name here

Changed to CannotEnableCrtStaticPointerAuth

asl · 2026-04-20T23:25:15Z

+**Tier: 3**
+
+The target enables Pointer Authentication Code (PAC) support in Rust on AArch64
+ELF based Linux systems using a pauthtest ABI (provided by LLVM) and


LLVM does not provide pauthtest ABI. This is C/C++ pointer authentication ABI. You may want to cross-ref to https://clang.llvm.org/docs/PointerAuthentication.html

asl · 2026-04-20T23:25:30Z

+
+The target enables Pointer Authentication Code (PAC) support in Rust on AArch64
+ELF based Linux systems using a pauthtest ABI (provided by LLVM) and
+pauthtest-enabled sysroot with custom musl, serving as a reference libc


ditto. And similar on other places in this document

asl · 2026-04-20T23:26:33Z

+
+## Cross-compilation toolchains and C code
+
+This target supports interoperability with C code. Use the pauthtest-enabled


Do not use pautest-enabled and similar things here...

tgross35 · 2026-04-24T02:50:57Z

Mentioned this elsewhere but the target should land as no-std first. The initial support should only be the bare minimum to get core building via --target, everything else can come as a followup.

(Fine to keep this PR around as a WIP of course)

View changes since the review

tgross35 · 2026-04-24T03:16:21Z

Probably worth a directory for pauth

View changes since the review

tgross35 · 2026-04-24T03:20:05Z

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 · 2026-04-24T09:11:48Z

Upstream PR submitted, closing this one.

Introduce aarch64-unknown-linux-pauthtest target 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: rust-lang#154759 * Part of: rust-lang#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](https://github.com/llvm/llvm-project/blob/main/llvm/unittests/TargetParser/TripleTest.cpp#L1407). > - 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](https://github.com/access-softek/musl) based) and sysroot, provided [through the build scripts](https://github.com/access-softek/pauth-toolchain-build-scripts/tree/master). > - 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.

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 88b623e to 3b3fcce Compare April 3, 2026 15:50

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 3b3fcce to e33dbf3 Compare April 3, 2026 17:25

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from e33dbf3 to 9e48aaa Compare April 3, 2026 18:24

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 9e48aaa to 4468c36 Compare April 3, 2026 19:08

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 4468c36 to c9fe7d6 Compare April 3, 2026 20:52

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from c9fe7d6 to 7ecdaa6 Compare April 4, 2026 05:55

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 7ecdaa6 to 65007e0 Compare April 4, 2026 06:57

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch from 65007e0 to 566b1b6 Compare April 4, 2026 08:00

This comment has been minimized.

Sign in to view

jchlanda force-pushed the jakub/pauthtest branch 3 times, most recently from 0db30a1 to 5bc3e48 Compare April 7, 2026 14:02

kovdan01 reviewed Apr 15, 2026

View reviewed changes

asl reviewed Apr 15, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

kovdan01 reviewed Apr 17, 2026

View reviewed changes

jchlanda force-pushed the jakub/pauthtest branch from 7b438ad to 0fb92bd Compare April 17, 2026 12:27

jchlanda added 7 commits April 17, 2026 13:56

Introduce aarch64-unknown-linux-pauthtest

528c831

Define ptrauth call operand bundle and introduce const_ptr_aut

7005959

`const_ptr_auth` wraps aroudn `LLVMRustConstPtrAuth`, which provides a way to decorate a function pointer in `ConstPtrAuth`.

New signature of get_fn_addr, teach Rust how to sign fn pointers

154b381

Allow PAC metadata to be passed to `get_fn_addr` and related API changes.

Add pauth attributes and first IR tests

666af81

The set of supported attributes is: function * "aarch64-jump-table-hardening" * "ptrauth-auth-traps" * "ptrauth-calls" * "ptrauth-indirect-gotos" * "ptrauth-returns" module * "ptrauth-elf-got" * "ptrauth-sign-personality"

Add support for init/fini signing and correctly sign extern weak globals

b994701

Also add flag for ELF-GOT signing.

Teach bootstrap how to build rust_test_helpers for pauthtest

0491274

Also: * update tests to force dynamic library when targetting pauthtest * various test fixes * introduce end-to-end tests for pauthtest (in run-make)

For pauthtest landing pads must be signed

e2a6ac3

jchlanda force-pushed the jakub/pauthtest branch from a63791c to e2a6ac3 Compare April 17, 2026 14:20

asl reviewed Apr 20, 2026

View reviewed changes

TODO: Add to INTRODUCE

6bf047f

This comment has been minimized.

Sign in to view

jchlanda added 2 commits April 21, 2026 12:51

TODO: Add to TEACH BOOTSTRAP

ba2045e

TODO: Add to ATTRIBUTES

e4537ba

jchlanda force-pushed the jakub/pauthtest branch from 2077515 to e4537ba Compare April 21, 2026 12:59

tgross35 reviewed Apr 24, 2026

View reviewed changes

jchlanda closed this Apr 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 24, 2026

madsmtm mentioned this pull request Apr 24, 2026

Introduce aarch64-unknown-linux-pauthtest target #155722

Open

	// FIXME(jchlanda) This is not an exhaustive list of all `pauthtest`-related attributes, but
	// FIXME(jchlanda) This is not an exhaustive list of all `ptrauth`-related attributes, but


		## Cross-compilation toolchains and C code

		This target supports interoperability with C code. Use the pauthtest-enabled

Uh oh!

Uh oh!

Conversation

jchlanda commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asl Apr 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asl Apr 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

kovdan01 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

asl left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jchlanda commented Apr 3, 2026 •

edited

Loading

asl Apr 15, 2026 •

edited by rustbot

Loading

asl Apr 15, 2026 •

edited by rustbot

Loading

kovdan01 left a comment •

edited by rustbot

Loading

asl left a comment •

edited by rustbot

Loading

tgross35 Apr 24, 2026 •

edited by rustbot

Loading

tgross35 Apr 24, 2026 •

edited by rustbot

Loading

tgross35 Apr 24, 2026 •

edited by rustbot

Loading