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

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

This PR introduces aarch64-unknown-linux-pauthtest target, that 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.

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 defined 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 pauth_enable_elf_got, off by
default)

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-14T10:58:07Z

compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp

+  if (!C)
+    return Ptr;
+  if (!C->getType()->isPointerTy())
+    return Ptr;
+  if (isa<UndefValue>(C) || isa<ConstantPointerNull>(C))
+    return Ptr;


View changes since the review

Do we expect values non-conforming to these conditions being passed to this function? Locally, I've commented out these lines, and nothing seems to be broken.

So, can we safely convert these to assertions? Or, maybe, some checks which would be present in release mode as well (and would panic when mismatch is detected)? Please just explain which contract do we have, who is responsible for these checks and whether the checks need to be just assertions or if we need to make them panicking or smth.

If there's a reason why we need to keep the current behavior, it's totally fine. But if so, can we somehow rename the function? Now it's name might make one think that we always wrap the underlying constant pointer value to ptrauth constant. But we also have this chunk of logic returning the exact input value w/o any change, and this is not clear from the function name.

Fair.
With it now being wrapped in const_ptr_auth and only two call sites we can't violate the contract.
However it is still a symbol that can be accessed freely. I'm going to change it to asserts.

jchlanda · 2026-04-14T11:30:05Z

Sure, I'll follow up on that. I don't expect all that subset to pass though.

I suppose that it's worth at least identifying where the root cause of the issue is: frontend or backend. Like, are IRs generated for aarch64-unknown-linux-musl and aarch64-unknown-linux-pauthtest different (so we generate them differently on Rust side and probably we should generate them identically), or are IRs identical and we for some reason behave differently on LLVM side.

If it's a frontend issue, it's actually probably worth fixing in the scope of this PR (unless it's terribly complex and time-consuming). If this is a backend issue, we'll fix that separately in LLVM

Looks like there is no bug in there, it's an expected behaviour. I'm guessing that when you compiled for musl it went with a +v8a. However when targeting pauthtest we request v8.3a, which includes support for lse. See: https://github.com/llvm/llvm-project/blob/8e2a5e37eaf638c536dd71cb685843e8cb2aed2c/llvm/lib/Target/AArch64/AArch64Features.td#L964. bl __aarch64_cas4_relax - which is what the test checks against - is a software fallback, whereas on new enough HW we get a corresponding instruction: cas w8, w9, [x0].

You can verify that by either changing the arch to v3.8a or explicitly enabling lse.

Will disable the test and add a comment.

kovdan01 · 2026-04-14T11:33:39Z

Will disable the test and add a comment.

What I'm worried about is that in compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_pauthtest.rs we have features: "+v8.3a,+outline-atomics,+pauth". So we explicitly request +outline-atomics (the same is done for the musl target, so it looks totally OK for pauthtest target).

And my understanding was that if we add +outline-atomics, we must indeed outline them no matter if we actually support them or not. But I might be wrong and I'd just like to hear your thoughts on this

kovdan01 · 2026-04-14T11:45:42Z

compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_pauthtest.rs

+
+        options: TargetOptions {
+            env: Env::Pauthtest,
+            features: "+v8.3a,+outline-atomics,+pauth".into(),


View changes since the review

I've just found this in llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:

// Generate outline atomics library calls only if LSE was not specified for // subtarget if (Subtarget->outlineAtomics() && !Subtarget->hasLSE()) {

And I've also inspected test/CodeGen/AArch64/atomic-ops-lse.ll and it looks like that yes, having both +lse and +outline-atomics makes the latter ineffective.

So, I suppose it's worth deleting +outline-atomics from here because it's just misleading. And might be also worth adding a comment explaining that pauthtest target is different to other aarch64-linux targets (all including +outline-atomics), because v8.3a includes lse, and lse makes outline-attomics ineffective.

Sorry, posted It in a wrong thread:

Targeting musl with: "target-features"="+lse,+outline-atomics", results:

.file "aarch64_outline_atomics.bca081c37e0149a7-cgu.0" .text .globl _RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange // -- Begin function _RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange .p2align 2 .type _RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange,@function _RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange: // @_RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange .cfi_startproc // %bb.0: // %start mov w9, #10 // =0xa mov w8, wzr cas w8, w9, [x0] ret .Lfunc_end0: .size _RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange, .Lfunc_end0-_RNvCsgc3x3YG0xfv_23aarch64_outline_atomics16compare_exchange .cfi_endproc // -- End function .ident "rustc version 1.97.0-dev" .section ".note.GNU-stack","",@progbits .addrsig

I guess that means, that we should not be requesting outline-atomics, as the compiler will never be able to provide it.

kovdan01 · 2026-04-14T12:49:51Z

src/doc/rustc/src/platform-support/aarch64-unknown-linux-pauthtest.md

+pauthtest-enabled sysroot with custom musl, serving as a reference libc
+implementation.
+
+Supported features include:


"Trapping" still looks inconsistent

kovdan01 · 2026-04-14T12:52:36Z

src/doc/rustc/src/platform-support/aarch64-unknown-linux-pauthtest.md

+in Rust can be found at
+[#148640](https://github.com/rust-lang/rust/issues/148640).
+
+Existing compiler options such as `-mbranch-protection` provide limited pointer


View changes since the review

Is it -mbranch-protection for Rust? My understanding was that it's -Z branch-protection (while its indeed -mbranch-protection for clang). See also src/doc/unstable-book/src/compiler-flags/branch-protection.md.

Also, I'm not sure if it's worth talking about BTI - I doubt that anyone would mess BTI with pauthtest. But for pac-ret and pauthtest - it's non-obvious for new-comers because both these are based on the same PAC extension for aarch64 CPUs

kovdan01 · 2026-04-14T13:09:49Z

src/doc/rustc/src/platform-support/aarch64-unknown-linux-pauthtest.md

+Clang-based toolchain. In this case, no wrapper script is required,
+`<toolchain_root>/bin/aarch64-linux-pauthtest-clang` can be used directly.
+
+## Building the target


Removing the second one, both paragraphs should belong to the same header.

Is this update already present in this PR? Like, I'm still seeing the same header at lines 94 and 173.

kovdan01 · 2026-04-14T13:19:00Z

src/doc/rustc/src/platform-support/aarch64-unknown-linux-pauthtest.md

+`aarch64-unknown-linux-pauthtest` target enabled.
+
+For a comprehensive example of how to interact between C and Rust programs
+withing the testing framework please consult


View changes since the review

Typo: within

kovdan01 · 2026-04-14T13:19:33Z

src/doc/rustc/src/platform-support/aarch64-unknown-linux-pauthtest.md

+* 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)


View changes since the review

Nit: probably a comma missed before 'off'?

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

jchlanda added 14 commits April 14, 2026 08:57

TODO: Add to INIT/FINI

6f37ca7

TODO: Add to TEACH BOOTSTRAP

52a74ef

TODO: Add to TEACH BOOTSTRAP

604fb71

TODO: Add to INTRODUCE

8a33b60

TODO: Add to INTRODUCE

a6ada3d

TODO: Add to ATTRIBUTES

37a5cd9

TODO: Add to INTRODUCE

45ad45d

TODO: Add to INIT/FINI

2c78c27

TODO: Add to TEACH BOOTSTRAP

2a3e2d7

TODO: Add to INIT/FINI

05206d7

TODO: Add to ATTRIBUTES

d7a394c

TODO: Add to TEACH BOOTSTRAP

5ed4b1f

TODO: Add to INTRODUCE

4a17f9a

TODO: Add to INIT/FINI

0606d27

jchlanda force-pushed the jakub/pauthtest branch from 63e45fd to 0606d27 Compare April 14, 2026 09:13

TODO: Add to TEACH BOOTSTRAP

e0f1994

This comment has been minimized.

Sign in to view

jchlanda added 2 commits April 14, 2026 09:59

TODO: Add to TEACH BOOTSTRAP

1c84193

TODO: Add to INTRODUCE

2d949b2

kovdan01 reviewed Apr 14, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

TODO: Add to TEACH BOOTSTRAP

d4eb772

kovdan01 reviewed Apr 14, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

TODO: Add to INTRODUCE

9f2ac73

jchlanda force-pushed the jakub/pauthtest branch from 6ee8cab to 9f2ac73 Compare April 14, 2026 12:57

kovdan01 reviewed Apr 14, 2026

View reviewed changes

TODO: Add to INTRODUCE

d550d39

Uh oh!

Conversation

jchlanda commented Apr 3, 2026 • edited by rustbot 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.

This comment has been minimized.

kovdan01 Apr 14, 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!

jchlanda Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

jchlanda commented Apr 14, 2026

Uh oh!

kovdan01 commented Apr 14, 2026

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jchlanda Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

kovdan01 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

kovdan01 Apr 14, 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!

jchlanda Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

kovdan01 Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

kovdan01 Apr 14, 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!

jchlanda Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

kovdan01 Apr 14, 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!

jchlanda Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jchlanda commented Apr 3, 2026 •

edited by rustbot

Loading

kovdan01 Apr 14, 2026 •

edited by rustbot

Loading

kovdan01 Apr 14, 2026 •

edited

Loading

kovdan01 Apr 14, 2026 •

edited by rustbot

Loading

kovdan01 Apr 14, 2026 •

edited by rustbot

Loading

kovdan01 Apr 14, 2026 •

edited by rustbot

Loading