Skip to content

Arm64: [PAC-RET] Add Pointer Authentication support for Arm64 - #125436

Open
SwapnilGaikwad wants to merge 186 commits into
dotnet:mainfrom
SwapnilGaikwad:github-add-pac
Open

SwapnilGaikwad wants to merge 186 commits into
dotnet:mainfrom
SwapnilGaikwad:github-add-pac

Conversation

@SwapnilGaikwad

@SwapnilGaikwad SwapnilGaikwad commented Mar 11, 2026 •

Copy link
Copy Markdown
Contributor

This PR adds support for Pointer Authentication (PAC) on Arm64. Pointer Authentication (PAC) is an Armv8.3+ security feature designed to mitigate Return-Oriented Programming (ROP) attacks by cryptographically signing return addresses. While using PAC, we store a signed return address, instead of the plain address, on the stack and later authenticate it before returning from a function. It ensures control flow returns to the intended caller.

More details on PAC and its role in software security can be found (here).

  • The current implementation of PAC is turned off by default, but can be turned on by setting DOTNET_JitPacEnabled=1.
  • PAC protects link register (LR) by signing it in the prolog (using paciasp) before it is split, using the current SP as the modifier. It then authenticates the LR in the epilog (using autiasp) before the function returns. If the signature is invalid, the execution fails with SIGILL.
  • When the runtime needs to read or overwrite a return address during hijacking for GC, it now strips the PAC (using xpaclri) and re-signs the new target address before storing it back.

ToDos

  • Disable PAC by default before merge.
  • Restore the original frame layout that used pre-indexed variant of stp to store FP/LR.
  • Authenticate the return address instead of stripping in return address hijacking and unwinding.
  • Identify increased binary size for System.*.dll
  • Determine performance regressions using benchmarks such as OrchirdCMS.

Contributes to #109457

This PR adds support for Pointer Authentication (PAC) on Arm64. Pointer Authentication (PAC) is an Armv8.3+ security feature designed to mitigate Return-Oriented Programming (ROP) attacks by cryptographically signing return addresses. While using PAC, we store a signed return address, instead of the plain address, on the stack and later authenticate it before returning from a function. It ensures control flow returns to the intended caller.

More details on PAC and its role in software security can be found ([here](https://llsoftsec.github.io/llsoftsecbook/#sec:pointer-authentication)).

- The current implementation of PAC is turned off by default, but can be turned on by setting DOTNET_JitPacEnabled=1.
- PAC protects link register (LR) by signing it in the prolog (using `paciasp`) before it is split, using the current SP as the modifier. It then authenticates the LR in the epilog (using `autiasp`) before the function returns. If the signature is invalid, the execution fails with `SIGILL`.
- - When the runtime needs to read or overwrite a return address during hijacking for GC, it now strips the PAC (using `xpaclri`) and re-signs the new target address before storing it back.
- To simply tracking the SP in return address hijacking, we avoid using the pre-indexed variant of storing FP/LR on stack (e.g., `stp fp,lr,[sp,-#framesz]! `) to simply tracking the SP in return address hijacking. We obtain the value of SP at the time of signing the LR from the location of the current FP.  We can't use this approach when the pre-indexed `stp` is used because we don't know the`#framesz`.
- The updated prolog/epilog sequences generated by the JIT now look like:

 // Prolog
 sub     sp, sp, #framesz
 paciasp                 ; sign LR with A-key + SP
 stp     fp, lr, [sp]

 // Epilog
 ldp     fp, lr, [sp]
 autiasp                 ; authenticate LR
 add     sp, sp, #framesz
 ret

ToDos:
[] Restore the original frame layout that used pre-indexed variant of `stp` to store FP/LR.
[] Authenticate the return address instead of stripping in return address hijacking and unwinding.
[] Identify increased binary size for System.*.dll
[] Determine performance regressions using benchmarks such as OrchirdCMS.
@dotnet-policy-service dotnet-policy-service Bot added the community-contribution Indicates that the PR has been added by a community member label Mar 11, 2026
@jkotas jkotas added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI arch-arm64 and removed area-NativeAOT-coreclr labels Mar 11, 2026
@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

@SwapnilGaikwad

Copy link
Copy Markdown
Contributor Author

[edit] It seems that this PR is broken into 3 parts including #128950.
What's the status of this PR? @jkotas, does this look good after the NAOT outerloop test? @SwapnilGaikwad, please address a copilot comment (#125436 (comment)) and resolve all comments that are already addressed.

This is a no-merge PR Swapnil used for testing, because the 3 parts went in off-by-defaut.

I think this can be closed but I want to double check first - @SwapnilGaikwad (or @a74nh if Swapnil is still out) can we close this PR?

Yes, @dhartglassMSFT is right. This PR is for testing purpose only where we enable the PAC feature that is disabled by default on the main branch. We maintained this PR to test PAC changes in CI when enabled.
The changes to JIT, Coreclr/VM and NativeAOT are merged. The CDAC changes, required for debuggers, are still in progress so we still have this PR. We will close this PR once they are finished.


Data.InlinedCallFrame icf = _target.ProcessedData.GetOrAdd<Data.InlinedCallFrame>(framePtr);
TargetCodePointer returnAddress = icf.CallerReturnAddress;
TargetCodePointer returnAddress = CodePointerUtils.StripPtrAuthFromReturnAddress(icf.CallerReturnAddress, _target);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can, I'd like to avoid stripping the pointer authentication on TargetCodePointer. This gives us two different types of TargetCodePointers, without being able to differentiate them.

Instead, I'd suggest we update AddressFromCodePointer to strip the pointer auth and make sure that we don't make assumptions about the TargetCodePointer. There is probably places where we will need to convert from the TargetCodePointer -> TargetPointer.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to strip the pointer authentication only when dealing with return addresses. I would suggest we do the stripping only when converting a return address to a (code) pointer that is used by the rest of the system. It is what we are doing at runtime.

Fixes: dotnet#134912

- Stop treating SP adjustments as evidence of an epilog: they may occur
during stack allocation in the function body.
- Continue rejecting hijacking after FP or LR has been restored.
- For NativeAOT assert that signing SP equals CFA.
- Use the caller SP recovered by unwinding to sign hijacked return
addresses. This avoids reconstructing signing SP from frame offsets.
max-charlamb pushed a commit to dotnet/diagnostics that referenced this pull request Oct 7, 2026
Without PAC support `runtime-diagnostics (SOSTests windows-arm64 release
SOS)` pipeline is failing for the runtime PR
[#125436](dotnet/runtime#125436)

Strip pointer authentication bits from saved return-address candidates
before checking the preceding call instruction and resolving symbols.
DumpStackWorker reads raw stack memory, so needs to strip these bits.

Use a 47-bit mask for Windows user-mode addresses and 48-bit mask for
non-Windows targets.

cc: @dotnet/arm64-contrib @dhartglassMSFT

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arch-arm64 area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI community-contribution Indicates that the PR has been added by a community member NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants