AD3018: EnableArmPAC¶

Summary¶

Description¶

This rule checks that AArch64 ELF binaries have ARM Pointer Authentication Codes (PAC) enabled. PAC provides hardware-based protection against Return-Oriented Programming (ROP) attacks by cryptographically signing return addresses.

Why This Matters¶

ARM Pointer Authentication (PAC) provides cryptographic protection for pointers, making ROP attacks cryptographically expensive to execute. Unlike software canaries, PAC uses hardware-accelerated cryptography that cannot be bypassed through information leaks alone.

Cryptographic vs. Randomization Defense¶

Stack Canary (randomization):
  - Random value on stack
  - If attacker leaks it, defense broken
  - One leak = complete bypass

PAC (cryptographic):
  - Cryptographic signature per pointer
  - Signature depends on: pointer, context, secret key
  - Leaking one signature doesn't help with others
  - Key is in hardware, cannot be extracted

How PAC Protects Return Addresses¶

; Function prologue
paciasp         ; Sign x30 (link register) with SP context
stp x29, x30, [sp, #-16]!

; Function body...

; Function epilogue
ldp x29, x30, [sp], #16
retaa           ; Verify signature, then return
                ; If tampered → exception

PAC Key Architecture¶

Keys are managed by the kernel and inaccessible to userspace.

Security Properties¶

Attack Difficulty with PAC¶

Without PAC:
  1. Overflow buffer
  2. Overwrite return address with ROP chain
  3. Done

With PAC:
  1. Overflow buffer
  2. Overwrite return address
  3. Need valid PAC for new address
  4. PAC = f(address, context, secret_key)
  5. Can't compute without key
  6. Attack fails

PAC + BTI Combined Protection¶

Using both provides comprehensive protection.

Performance Characteristics¶

Hardware acceleration makes PAC practical for production.

Deployment Status¶

• ROP protection: PAC signs return addresses to detect tampering
• Cryptographic security: Uses hardware keys for signing
• Low overhead: Minimal performance impact with hardware support
• Defense in depth: Complements BTI for comprehensive control-flow protection

Performance Considerations¶

PAC is designed for production use with minimal overhead:

Operation costs:

Workload impact:

Trade-offs: - All code in the call chain should be PAC-enabled for full protection - Mixing PAC and non-PAC code reduces security benefit - Libraries should be recompiled with PAC support

How PAC Works¶

1. On function entry: The return address is signed using PACIASP instruction
2. Signature stored: The PAC is stored in unused upper bits of the pointer
3. On function return: The signature is verified using AUTIASP or RETAA
4. Tampering detected: If the PAC doesn't match, an authentication failure occurs

function:
    paciasp              ; Sign return address with key A and SP
    stp x29, x30, [sp, #-16]!
    ...
    ldp x29, x30, [sp], #16
    retaa                ; Return with authentication

How to Fix¶

Compile with branch protection¶

# Enable PAC for return addresses
gcc -mbranch-protection=pac-ret -o myapp myapp.c

# Enable both BTI and PAC (recommended)
gcc -mbranch-protection=standard -o myapp myapp.c

# Clang equivalent
clang -mbranch-protection=pac-ret+bti -o myapp myapp.c

Verify the fix¶

# Check for PAC instructions
objdump -d myapp | grep -E "paciasp|autiasp|retaa"

# Check ELF properties
readelf -n myapp | grep -i "PAC"

Example¶

Fail: Binary does not have PAC enabled

# Standard return instruction
ret

Pass: Binary has PAC enabled

# PAC-protected return
paciasp
...
retaa

Requirements¶

• Compiler: GCC 9+ or Clang 8+
• CPU: ARMv8.3-A or later (with FEAT_PAuth)
• Kernel: Linux 5.0+ for PAC support

See Also¶

• AD3017: EnableArmBTI - Branch Target Identification
• ARM PAC Documentation