Pointer authentication config and user facing options by jchlanda · Pull Request #156712 · rust-lang/rust

jchlanda · 2026-05-18T13:03:50Z

This patch brings:

unified handling of pointer authentication options through:
-Zpointer-authentication, with possible values:
aarch64-jump-table-hardening, auth-traps, calls, elf-got,
function-pointer-type-discrimination, indirect-gotos, init-fini,
init-fini-address-discrimination, return-addresses. Toggled with
+/-.
centralized handling of pointer authentication features. Session holds
pointer_auth_config: Option<PointerAuthConfig>
encapsulation of schema for function pointers and init/fini through
PointerAuthSchema. This allowed for retiring of PacMetadata.
refactor enabling of pointer authentication in code, instead of
relying on the target (pauthtest) use the session

Co-authored-by: Daniil Kovalev <dkovalev@accesssoftek.com>

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)

This patch brings: * unified handling of pointer authentication options through: `-Zpointer-authentication`, with possible values: `aarch64-jump-table-hardening`, `auth-traps`, `calls`, `elf-got`, `function-pointer-type-discrimination`, `indirect-gotos`, `init-fini`, `init-fini-address-discrimination`, `return-addresses`. Toggled with `+`/`-`. * centralized handling of pointer authentication features. Session holds `pointer_auth_config: Option<PointerAuthConfig>` * encapsulation of schema for function pointers and init/fini through `PointerAuthSchema`. This allowed for retiring of `PacMetadata`. * refactor enabling of pointer authentication in code, instead of relying on the target (`pauthtest`) use the session

jchlanda · 2026-05-19T12:17:23Z

@davidtwco, @folkertdev, @tgross35, @madsmtm FWI this is a follow up to #155722 and #156548
This will have to be rebased once the above are merged.

rustbot · 2026-05-19T12:17:28Z

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

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

Some changes occurred in src/tools/compiletest

cc @jieyouxu

The GCC codegen subtree was changed

cc @antoyo, @GuillaumeGomez

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/doc/rustc/src/platform-support

cc @Noratrieb

This PR modifies tests/auxiliary/minicore.rs.

cc @jieyouxu

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

rustbot · 2026-05-19T12:17:31Z

r? @mejrs

rustbot has assigned @mejrs.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

rust-bors · 2026-05-23T22:52:23Z

☔ The latest upstream changes (presumably #156116) made this pull request unmergeable. Please resolve the merge conflicts.

mejrs · 2026-05-24T15:46:34Z

Hi, I am not qualified to review this.

r? madsmtm or reroll maybe

rustbot · 2026-05-24T15:46:39Z

madsmtm is not on the review rotation at the moment.
They may take a while to respond.

kovdan01 · 2026-05-25T10:55:53Z

+        // <llvm_root>/llvm/include/llvm/BinaryFormat/ELF.h.
+        // FIXME (jchlanda) extend possible values once we start supporting other platforms (for
+        // example: AARCH64_PAUTH_PLATFORM_BAREMETAL = 0x1);
+        let aarch64_pauth_platform_llvm_linux = 0x10000002;


Would it be better to use const instead of let here?

View changes since the review

kovdan01 · 2026-05-25T11:06:19Z

+}
+
+pub struct PointerAuthSchema {
+    pub kind: PointerAuthKind,


I suppose that your intention was to mimic the implementation in clang. It looks like that in clang checks against getKind() != Kind::None (for example, via isEnabled() member function or via cast to bool) are used to understand if we have some schema present or not. Your implementation seems to keep this kind field untouched and instead wrap the whole PointerAuthSchema in the Option wrapper.

So, it looks like we are just duplicating the 'optional' functionality. Can we just use the kind field for checking if the schema is none or not (just as we do in clang)?

View changes since the review

kovdan01 · 2026-05-25T11:10:29Z

+    fn get_fn_addr(
+        &self,
+        instance: Instance<'tcx>,
+        schema: Option<&PointerAuthSchema>,


Would it be better to rename the argument to smth like pointerAuthSchema? The function by itself is not pauth-related, so I suppose that the reader might not have all the context in their mind on "what kind of schema is meant" (unless they look at function signature here)

View changes since the review

kovdan01 · 2026-05-25T11:14:35Z

+    llfn: &'ll llvm::Value,
+    schema: &PointerAuthSchema,
+) -> &'ll llvm::Value {
+    if !cx.tcx.sess.pointer_authentication_functions() {


Is this check needed? My understanding was that we define schema argument somewhere earlier in the call stack based on the cx.tcx.sess.pointer_authentication_functions(), and if it's not set, the schema would just have kind == None.

So, can we delete the check and instead add an assertion against schema kind not being none?

I might be missing smth, and if so - I would appreciate your explanation on this topic

View changes since the review

kovdan01 · 2026-05-25T11:19:34Z

+
+/// Types of address discrimination.
+pub enum PointerAuthAddressDiscriminator {
+    /// Enable/disable hardware address discrimination.


Is the term "hardware address discrimination" used anywhere else in existing projects (mostly interesting - in clang)?

If yes, could you please refer me to such term usage cases?

If no, I would prefer to avoid introducing new terms here and try to stick with well-established wording. Actually, this "hardware" framing might be a bit misleading here (one might think it might be related to physical <-> virtual address mapping? while totally unrelated)

View changes since the review

kovdan01 · 2026-05-25T11:48:44Z

+    }
+    pub fn from_raw(raw: &[(PointerAuthOption, bool)], target: &Target) -> Option<Self> {
+        if target.cfg_abi != CfgAbi::Pauthtest {
+            return None;


Would it be feasible to support this for target with non-pauthtest CfgAbi (like how it's done in clang)?

If it's too challenging and you think that it's not worth including in this PR - could we at least emit some sort of error and not just silently ignore the flag values passed by user?

View changes since the review

kovdan01 · 2026-05-25T11:49:51Z

+//@[DISABLE_VT_PTR_TYPE] needs-llvm-components: aarch64
+//@[DISABLE_VT_PTR_TYPE] compile-flags: --target=aarch64-unknown-linux-pauthtest -Zpointer-authentication=-vt-ptr-type-discrimination
+//@[NONE] needs-llvm-components: aarch64
+//@[NONE] compile-flags: --target=aarch64-unknown-linux-pauthtest  -Zpointer-authentication=-aarch64-jump-table-hardening,-auth-traps,-calls,-indirect-gotos,-return-addresses,-init-fini,-init-fini-address-discrimination,-intrinsics,-typeinfo-vt-ptr-discrimination,-vt-ptr-addr-discrimination,-vt-ptr-type-discrimination


For -init-fini (signing disabled), is it somehow tested?

View changes since the review

kovdan01 · 2026-05-25T11:56:54Z

+                        cfg.function_pointers = None;
+                    }
+                }
+                PointerAuthOption::FunctionPointerTypeDiscrimination => {


While function pointer type discrimination support is not yet implemented and it's not in the "default" pauthtest configuration - can we safely emit an error on that to make things explicit?

I'm just not sure if there are any use cases which would benefit from silently setting this option while it's not affecting anything (compared to emitting a compile error - since silent ignore would just result in runtime error with any kind of C interop involved)

But if such cases exist - please let me know, I might be missing smth.

View changes since the review

jchlanda and others added 10 commits May 13, 2026 11:47

Introduce aarch64-unknown-linux-pauthtest

01ab5ef

Co-authored-by: Daniil Kovalev <dkovalev@accesssoftek.com>

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

d419bcc

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

Add pauth attributes and first IR tests

a2e2656

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

ef4e1e3

Also add flag for ELF-GOT signing.

Teach bootstrap how to build rust_test_helpers for pauthtest

b1a7b32

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

Override static libraries and warn on linking against that kind of libs

ec87aa2

Correctly set f128 math support for pauthtest

e98f285

Use target_env = "musl" & target_abi = "pauthtest"

e0c6f73

Add library support for aarch64-unknown-linux-pauthtest

27c6d20

Use target_env = "musl" & target_abi = "pauthtest" instead of env

72ea191