Adding Pointer-Authentication Protection For Free List Forward Edge

[Pengxiang-Huang]

Co-authored-by: Schrodinger ZHU Yifan i@zhuyi.fan

The implementation is largely based on the original code proposed in this issue: #838 @SchrodingerZhu

I did some correctness changes for the cmake; some minor fixes; and adding a few comments;

I run and verify this PAC feature on my local Mac environment with Apple Clang 17.

[Pengxiang-Huang]

@microsoft-github-policy-service agree

[SchrodingerZhu]

I think we can just -fptrauth-intrinsics to force enable ptrauth without enforcing armv8.3-a. Hardcoding the arch sounds a bit uneasy to me.

I remember being told inside llvm-libc that PAC hints are no-op on arch without support. So it might also be okay to have it on aarch64 as long as user enable the mitigation. I don't have time to exactly verify this. The following materials are summarized by Codex with ChatGPT 5.4 (high):

Arm’s AArch64 Programmer’s Guide says, in its “Use of the NOP space” section, that some authentication instructions are in NOP space,
and that apps or libraries using those NOP-space instructions can run on older processors without pointer-authentication support; older
processors just do not get the protection. The same section then explicitly distinguishes RETAx: it says the combined authenticate-and-
return instructions are not in NOP space and therefore are not compatible with processors that lack authentication support.
Source: [AArch64 Programmer’s Guide: Pointer authentication, BTI, and MTE](
(https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Providing%20protection%20for%20complex%20software.pdf)
at page 12 / lines 258-265
(https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Providing%20protection%20for%20complex%20software.pdf)

Arm’s compiler/security writeup says the same thing more directly: pac and aut instructions are in encoding space reserved as NOP space
in earlier architectures, so they are backward-compatible with Armv8-A; RETA is the exception and needs Armv8.3-A+.
Source: Code reuse attacks: the compiler story
(https://developer.arm.com/community/arm-community-blogs/b/tools-software-ides-blog/posts/code-reuse-attacks-the-compiler-story), lines
61-69 (https://developer.arm.com/community/arm-community-blogs/b/tools-software-ides-blog/posts/code-reuse-attacks-the-compiler-story)

Arm’s newer PAC/BTI article says the same in HINT-space terms: HINT-space instructions “will NOP on architectures that do not support
them,” and it maps paciasp to hint 25 and autiasp to hint 29.
Source: Part 2: Enabling PAC and BTI on AArch64 for Linux
(https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/p2-enabling-pac-and-bti-on-aarch64),
lines 151-178
(https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/p2-enabling-pac-and-bti-on-aarch64)

So the confirmation is:

• PAC* / AUT* in the NOP/HINT space: yes, legacy Armv8-A without PAUTH support ignores them.
• Fused return forms like RETAA / RETAB: no, those are the explicit exception.

[Copilot]

Pull request overview

This PR adds Pointer Authentication Code (PAC) support for forward-edge protection of freelist “next” pointers on AArch64, integrating it into snmalloc’s AAL feature system and wiring up CMake detection/flags.

Changes:

• Introduces a new PtrAuthentication AAL feature and generic AAL helpers for signing/authenticating stored pointers.
• Implements ARM AAL support using ptrauth.h (when available) and applies PAC to freelist forward-edge encoding/decoding.
• Extends CMake configuration to probe for PAC support and define/enable the feature.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
CMakeLists.txt	Detects PAC support and adds build flags / defines to enable the feature.
src/snmalloc/aal/aal.h	Adds generic AAL wrappers for pointer sign/auth operations.
src/snmalloc/aal/aal_consts.h	Adds PtrAuthentication to the AalFeatures enum.
src/snmalloc/aal/aal_arm.h	Implements ARM PAC sign/auth via ptrauth.h under feature guards.
src/snmalloc/mem/freelist.h	Uses PAC for freelist forward-edge protection when supported, else falls back to existing schemes.

[SchrodingerZhu]

@mjp41 could you take a look when you get time?

[mjp41]

Thanks for doing this. I have some high-level questions

• Can you validate this in CI? If we run on a recent Mac builder that uses Apple Silicon is this available to test?

• I am concerned the PAC is not obfuscating the pointers it just signs them. That means UAF could still be a disclosure gadget for another location. If we are running in a system that has some PAC pointers and some not, then disclosure is a bad thing as it can allow primitives for escalating an exploit.

Do you have thoughts on this? I am probably misunderstanding PAC on ARM.

[Pengxiang-Huang]

@mjp41 Thanks for your reply! Here is my humble opinion:

• It's necessary to add validation in CI, and I think we can verify this on macOS Apple Silicon CI job.

• This is very interesting to me! Yes. PAC only guarantees the integrity but not confidentiality. That is the known limitation, and potential stale-pointer replay attack (same slot but different time). But I would not argue it is less secure than XOR-pointers. XOR has its own limitations as well. XOR based encryption is not cryptographic secure such as ciphertext/plaintext recovery, or reading the keys from the known offset in userspace if compromised ASLR. For example, current freelist encode the nullptr at terminator using function store_null, it immediately gives key_next XOR key_tweak, that is very useful to get the key_next when key_tweak is known like NO_KEY_TWEAK =0 or exploitable. The nice things about PAC is that the key is stored in kernel space and it is cryptographically strong to provide a better integrity.

[mjp41]

@mjp41 Thanks for your reply! Here is my humble opinion:

• It's necessary to add validation in CI, and I think we can verify this on macOS Apple Silicon CI job.

Would you be able to adjust the Github actions to do that. You should be able to run the actions on a personal fork. I have to approve new contributors Github Action runs manually (Microsoft policy).

• This is very interesting to me! Yes. PAC only guarantees the integrity but not confidentiality. That is the known limitation, and potential stale-pointer replay attack (same slot but different time). But I would not argue it is less secure than XOR-pointers. XOR has its own limitations as well. XOR based encryption is not cryptographic secure such as ciphertext/plaintext recovery, or reading the keys from the known offset in userspace if compromised ASLR. For example, current freelist encode the nullptr at terminator using function store_null, it immediately gives key_next XOR key_tweak, that is very useful to get the key_next when key_tweak is known like NO_KEY_TWEAK =0 or exploitable. The nice things about PAC is that the key is stored in kernel space and it is cryptographically strong to provide a better integrity.

Thanks. I mostly agree with you. The XOR is not great. It is the bare minimum. It is pretty dependent on the adversary model if it provides any protection. I think offering this as an option would be great. I am not sure I know which is more important integrity or confidentiality. The back edge in the other part of the allocation provides a pretty strong integrity protection as it requires an arbitrary write to by pass, and by the time an attacker has an arbitrary write, the allocator is probably not going to be the route to increased priviledge.

[Pengxiang-Huang]

Can you validate this in CI? If we run on a recent Mac builder that uses Apple Silicon is this available to test?

I found out that the CI test for the last commit has shown that PAC was enabled and tested in macos 14/15 arm64 jobs: https://github.com/microsoft/snmalloc/actions/runs/23927647563/job/69791221236, SNMALLOC_COMPILER_SUPPORT_FPTRAUTH_INTRINSICS and SNMALLOC_COMPILER_SUPPORT_PACA_PACG succeed and ctests pass.

But it does not make PAC a required property for those runners, so it can fall back to the XOR approach and CI jobs will still pass. IIUC, do you want to create a CI job such that it fails when PAC is not available?