Pointer authentication code

개요

Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 하드웨어 보안 기법으로, 포인터를 사용하기 전에 이를 인증하여 메모리 안전성을 보장한다. PAC는 Cherry와 유사한 capability-based isolation 환경을 제공하여, Application과 Kernel 모두에서 포인터 무결성을 보장받을 수 있다. 이는 특히 Return-Oriented Programming (ROP), Use-After-Free(UAF), 버퍼 오버플로우 등 현대의 다양한 메모리 공격 기법에 대한 효과적인 방어 수단으로 활용된다.

PAC

Return oriented programming과 같은 공격을 방어하기 위해, 하드웨어 수준에서 Pointer address의 무결성(Integrity)를 검증하는 SFI(Software Fault Isolation) 방식을 제공한다. 이 방식을 통해 포인터가 메모리 접근 전에 정당한지를 하드웨어가 판단하고, 비정상일 경우 접근을 차단한다.

PAC는 포인터가 생성될 때, 사용된 콘텍스트(예: 함수 호출 시의 base pointer, stack pointer 등)와 암호화된 비밀 키를 바탕으로 Message authentication code를 생성하고, 포인터의 상위 비트에 이 정보를 삽입한다. 이후 포인터가 다시 사용될 때, 동일한 키와 콘텍스트를 통해 무결성 확인을 수행하며, 불일치 시 하드웨어 fault를 발생시킨다. 이러한 방식은 특히 ROP chain 탐지, Spatial 및 Temporal memory corruption 예방에 효과적이다.

PAC Instruction

<function prologue>
  paciasp                 ; sign (lr=x30) - SP를 기반으로 PAC 생성
  stp fp, lr, [sp, #0]    ; frame pointer와 link register를 저장
<function body>
<function epilogue>
  ldp fp, lr, [sp, #0]    ; 저장된 값 복원
  autiasp                 ; authentication
  ret                     ; 함수 복귀

PAC_A_B: 레지스터 B에 있는 포인터에 대해 A 키를 사용하여 PAC를 생성. 예: PACIASP는 Instruction key (IA)로 SP 기반 인증.
AUT_A x: A 키를 사용해 x 레지스터의 포인터 인증을 수행. 실패 시 fault 발생.
XPAC x: 인증 실패 시 PAC를 제거해 포인터를 복원(의심 상황 진단용으로 사용).
PAC-aware Load/Store 명령어:
- ARMv8.3-A부터 도입된 Load/Store 명령어 확장으로, PAC가 적용된 포인터를 자동으로 인증하면서 로드하거나 저장할 수 있다.
- 주로 pointer-authenticated 구조체나 함수 포인터 테이블 등에서 유용하게 사용된다.
- 주요 명령어 예시는 다음과 같다:
  - LDRAA Rt, [Rn]: authenticated address를 로드하고, 인증이 성공하면 Rt에 값을 저장.
  - LDG Rt, [Rn]: tagged pointer를 인증하고 로드.
  - STG Rt, [Rn]: 인증된 pointer를 메모리에 저장.

  ; PAC된 포인터를 로드하는 예시
  ldraa x0, [x1]     ; x1이 가리키는 주소에서 PAC 인증된 값을 x0에 로드

  ; PAC된 포인터를 저장하는 예시
  paciza x2          ; x2에 대한 PAC 생성 (IA key 사용)
  stg x2, [x3]       ; PAC된 x2 포인터를 메모리에 저장

장점

하드웨어 기반 인증으로 기존 Software-only 방식보다 빠르고 강력한 포인터 보호를 제공
기존의 PAC-enabled 바이너리는 ARM TrustZone과 함께 사용할 경우 효과적인 격리 구조를 구현할 수 있음
기존 공격 방식(RSP, heap spraying 등)의 무력화를 유도하며, ROP gadget 연결 시도에 대해 실패 가능성을 높임

단점

PAC는 컴파일 타임 혹은 링커 단계에서 적용되므로 기존 바이너리에는 적용이 불가능하며, 소스 레벨에서의 수정 혹은 설정이 요구됨
PAC를 사용하기 위해서는 반드시 컴파일러 또는 어셈블러의 지원이 필요하다. 따라서 이는 Transparent한 방어 기법이 아니며, 코드 수준의 명시적인 구현 혹은 설정이 요구됨
성능 저하가 발생할 수 있으며, 특히 Performance-critical 컴포넌트에서는 눈에 띄는 오버헤드가 발생할 수 있음
- 예: SPEC CPU2006의 sjeng 벤치마크 기준으로 PAC 도입 후 성능이 3배까지 저하된 사례가 보고됨
NaCl이나 WebAssembly 기반의 Software Isolation에 비해 여전히 유연성에서 한계를 보일 수 있음
일부 연구 결과에 따르면, PAC 우회를 시도하는 취약점(exploit primitive)도 존재하므로 절대적인 방어 수단은 아님

참고

Limitations and Opportunities of Modern Hardware Isolation Mechanisms (Usenix ATC'24)
velog.io/@pensieveview/Pointer-authentication
ARM Architecture Reference Manual for ARMv8-A, Section on Pointer Authentication
PAC in Apple A12 and M1 Chips - Trail of Bits