Support Pointer Authentication (PAC) for ARM64e #7

Activity

1. mingxwa

   added

   enhancementNew feature or requestNew feature or request

   p1

   security

   on Jan 29, 2026
2. mochaaP commented on Mar 11, 2026

   

   mochaaP

   on Mar 11, 2026

   Contributor

   More actions

   https://clang.llvm.org/docs/PointerAuthentication.html

   If I read the docs correctly, C++ function pointers are already signed automatically if the compiler supports them.

   If we want stronger guarantees:

   • For the function pointers, how do we derive the discriminator?
     The default signing scheme uses ptrauth_key_asia + ptrauth_string_discriminator on the function pointer type. Do we want to extend it to the full mangled function name for the facade?
   • For the pointers to a function table, do we want to discriminate between different facades?
     C++ vtables use ptrauth_key_asda + constant 0 discriminator (not discriminated) for code size and performance reasons.

   also note that if you use address diversity (ptrauth_key_asd*), the pointer will no longer be trivially relocatable.
3. mingxwa commented on Mar 13, 2026

   

   mingxwa

   on Mar 13, 2026

   MemberAuthor

   More actions

   Hi @mochaaP,

   Thank you for the insights and references. I have not fully explored the PAC design space for Proxy yet, so I do not want to commit to a specific scheme prematurely. My current view is:

   • PAC-specific hardening is not a primary feature of the library, so any additional support should be optional and users should be able to opt out.
   • My understanding is that address diversity provides stronger protection than a pure discriminator, so if the platform supports it, I would want us to support an opt-in mode that can use address diversity for the vptr / function-table pointer.
   • If ordinary C++ function pointers are already signed automatically by the compiler when PAC is available, then the remaining question is what extra library-level controls are actually worth adding beyond that baseline.

   The main trade-offs to evaluate seem to be security benefit vs. performance, code size, portability, and relocatability. I am open to further discussion and concrete design proposals here.