Arm Permission Overlay Extension (POE)

📝 Permission Indirection / Overlay Extension?

ARMv8.9-A / ARMv9.4-A 에서 추가된 메모리 접근 제어 기법으로, page table을 수정하거나 TLB invalidation 없이 메모리 영역의 접근 권한을 동적으로 제한하는 것을 목적으로 한다.

PAC, MTE가 각각 control flow 무결성과 메모리 태깅을 담당했다면, 이번에 다룰 PIE + POE는 메모리 도메인 격리를 하드웨어 레벨에서 다루는 기법이다.

POE를 제대로 이해하려면 ARMv8.9에서 함께 도입된 Permission Indirection Extension (PIE) 를 먼저 짚어야 한다. 둘은 spec상 독립적인 feature지만, POE는 PIE의 한계를 해결하기 위해 설계된 보완 기법이기 때문이다.

---

📝 Background

Intel MPK는 알고 있었나요?

x86 진영에서는 이미 Intel Memory Protection Keys (MPK) 라는 비슷한 기능이 있었다.
MPK는 userspace에서 page table entry를 수정하지 않고도 PKRU 레지스터 하나만 바꿔서 특정 메모리 도메인의 read/write를 빠르게 on/off할 수 있는 기법인데, syscall이나 TLB flush 없이 유저 공간에서 권한을 변경한다는 점이 핵심이었다.

ARM에도 ARMv7 시절 Memory Domains라는 비슷한 개념이 있었다. 하지만 DACR (Domain Access Control Register)는 EL0에서 접근이 불가능했고, AArch64에서는 아예 deprecated 되었다. 이걸 제대로 다시 만들겠다고 나온 게 PIE와 POE다.

기존 direct permission 방식의 한계

AArch64의 기존 permission 모델은 direct 방식이다. PTE의 몇 가지 비트들이 해당 페이지의 권한을 직접 인코딩한다.

PTE[54] = UXN  (User eXecute Never)
PTE[53] = PXN  (Privileged eXecute Never)
PTE[51] = DBM/WRITE
PTE[6]  = AP[1] (USER accessible)

이 방식은 단순하고 직관적이지만, 두 가지 문제가 있다.

첫째, 표현 가능한 permission 조합이 제한적이다. 위 4개 비트의 조합으로는 기본적인 r/w/x 정도만 표현 가능하고, 예를 들어 "읽기는 가능하지만 쓰기는 특수 instruction으로만" 같은 세밀한 권한은 표현할 방법이 없다. (GCS가 필요로 하는 바로 그 권한이다)

둘째, 권한을 변경하려면 비용이 크다. mprotect() syscall을 통해 PTE를 수정해야 하므로 필연적으로 kernel mode 전환, TLB invalidation, 멀티코어 환경에서는 TLB shootdown IPI까지 따라온다. JIT compiler, sandbox, memory isolation이 빈번한 런타임 환경에서는 이 비용이 꽤 크다.

---

📝 Permission Indirection Extension (PIE)

PTE의 비트를 "권한 그 자체"가 아닌 "권한 테이블의 인덱스"로 쓰자!

PIE (FEAT_S1PIE)는 permission 인코딩 방식을 indirect하게 바꾼다. 기존에 permission 비트로 사용하던 PTE 필드들을 PIIndex (Permission Indirection Index) 로 재활용하고, 실제 권한은 별도 레지스터에 정의된 테이블에서 lookup하는 방식이다.

PIIndex: PTE에서 domain index 추출

PIE가 활성화 (TCR2_EL1.PIE = 1) 되면 PTE의 4개 비트가 4-bit PIIndex로 재해석된다.

PIIndex[3] ← PTE[54] UXN  (User eXecute Never)
PIIndex[2] ← PTE[53] PXN  (Privileged eXecute Never)
PIIndex[1] ← PTE[51] WRITE/DBM
PIIndex[0] ← PTE[6]  USER  (AP[1])

PIIndex는 연속된 비트 필드가 아니라 PTE 내 4개의 분산된 비트를 조합해서 만드는 index다. 그래서 Linux 커널에서 pte_pi_index()라는 별도 함수로 각 비트를 수집해서 계산한다.

4-bit이므로 0~15, 총 16개의 domain을 정의할 수 있다.

PIRE0_EL1 / PIR_EL1: domain별 실제 권한 정의

PIIndex로 lookup할 실제 권한은 두 개의 레지스터에 정의된다.

레지스터	대상 EL	역할
PIRE0_EL1	EL0 (userspace)	같은 PIIndex에 대해 EL0에 부여할 권한
PIR_EL1	EL1 (kernel)	같은 PIIndex에 대해 EL1에 부여할 권한

두 레지스터가 존재하는 이유는 domain 수를 늘리려는 게 아니라, 동일한 PIIndex에 대해 EL0와 EL1이 서로 다른 권한을 가질 수 있도록 하기 위해서다. 각 레지스터가 독립적으로 16개 domain의 permission을 정의하지만, 총 domain 수는 16개다.

각 레지스터는 64-bit이며, domain당 4-bit씩 permission을 정의한다.

PIRE0_EL1 또는 PIR_EL1:
[63:60] perm15 : r, w, x, gcs
[59:56] perm14 : r, w, x, gcs
...
[3:0]   perm0  : r, w, x, gcs

16개 domain이 실제로 지칭하는 것들

PIIndex의 16개 domain은 "새로운 메모리 구역 16가지"가 아니다. 기존 PTE permission 비트 4개의 모든 조합 (2⁴ = 16)이 그대로 index로 재활용되기 때문에, 각 index는 기존의 page type과 1:1 대응된다.

Linux 커널 pgtable-prot.h에 주석으로 전체 매핑이 명시되어 있다:

/* 0x0: PAGE_DEFAULT                                         */
/* 0x1: PTE_USER                          (미사용)           */
/* 0x2: PTE_WRITE                         (미사용)           */
/* 0x3: PTE_WRITE | PTE_USER              (미사용)           */
/* 0x4: PAGE_EXECONLY      PTE_PXN                          */
/* 0x5: PAGE_READONLY_EXEC PTE_PXN | PTE_USER               */
/* 0x6: PTE_PXN | PTE_WRITE               (미사용)           */
/* 0x7: PAGE_SHARED_EXEC   PTE_PXN | PTE_WRITE | PTE_USER   */
/* 0x8: PAGE_KERNEL_ROX    PTE_UXN                          */
/* 0x9: PAGE_GCS_RO        PTE_UXN | PTE_USER               */
/* 0xa: PAGE_KERNEL_EXEC   PTE_UXN | PTE_WRITE              */
/* 0xb: PAGE_GCS           PTE_UXN | PTE_WRITE | PTE_USER   */
/* 0xc: PAGE_KERNEL_RO     PTE_UXN | PTE_PXN               */
/* 0xd: PAGE_READONLY      PTE_UXN | PTE_PXN | PTE_USER     */
/* 0xe: PAGE_KERNEL        PTE_UXN | PTE_PXN | PTE_WRITE    */
/* 0xf: PAGE_SHARED        PTE_UXN | PTE_PXN | PTE_WRITE | PTE_USER */

실제로 Linux에서 각 domain에 부여하는 permission은 PIE_E0 (→ PIRE0_EL1) 와 PIE_E1 (→ PIR_EL1) 로 정의된다.

// EL0 permission table (PIRE0_EL1)
#define PIE_E0 (
    PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS),           PIE_GCS)    // 0xb: GCSSTR만 허용
    PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO),        PIE_R)      // 0x9: 읽기만
    PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY),      PIE_X_O)    // 0x4: 실행만 (overlay on)
    PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_RX_O)   // 0x5: 읽기+실행 (overlay on)
    PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC),   PIE_RWX_O)  // 0x7: 읽쓰실 (overlay on)
    PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY),      PIE_R_O)    // 0xd: 읽기만 (overlay on)
    PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED),        PIE_RW_O))  // 0xf: 읽쓰 (overlay on)

// EL1 permission table (PIR_EL1)
#define PIE_E1 (
    PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS),           PIE_NONE_O) // 0xb: 접근 불가
    PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO),        PIE_NONE_O) // 0x9: 접근 불가
    PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY),      PIE_NONE_O) // 0x4: 접근 불가
    PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_R)      // 0x5: 읽기만
    PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC),   PIE_RW)     // 0x7: 읽쓰
    PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY),      PIE_R)      // 0xd: 읽기만
    PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED),        PIE_RW)     // 0xf: 읽쓰
    PIRx_ELx_PERM(pte_pi_index(_PAGE_KERNEL_ROX),    PIE_RX)     // 0x8: 읽기+실행
    PIRx_ELx_PERM(pte_pi_index(_PAGE_KERNEL_EXEC),   PIE_RWX)    // 0xa: 읽쓰실
    PIRx_ELx_PERM(pte_pi_index(_PAGE_KERNEL_RO),     PIE_R)      // 0xc: 읽기만
    PIRx_ELx_PERM(pte_pi_index(_PAGE_KERNEL),        PIE_RW))    // 0xe: 읽쓰

여기서 주목할 점이 두 가지 있다.

GCS permission이 PIE 없이는 불가능한 이유: PAGE_GCS (0xb)는 direct model에서 PTE_UXN | PTE_WRITE | PTE_USER로, "UXN이면서 USER 접근 가능"이라는 모순적인 조합이었다. PIE 하에서는 이 비트 조합을 index로 재해석해서 PIE_GCS라는 새 permission을 부여할 수 있게 된다. "일반 write는 막고 GCSSTR instruction으로만 쓸 수 있는" GCS 전용 권한이 바로 이것이다. GCS는 PIE 없이는 표현 자체가 불가능하다.

_O suffix의 의미: PIE_RW_O처럼 _O가 붙은 encoding은 "POE overlay 적용 가능" 버전이다. EL0용 PIRE0_EL1에서는 전부 _O suffix 버전을 사용해야 POE와 함께 동작한다. EL1용 PIR_EL1에는 overlay가 적용되지 않으므로 _O 없는 버전을 쓴다.

PIE의 한계

PIE로 더 풍부한 권한 표현이 가능해졌지만, 권한 변경 비용 문제는 여전히 해결되지 않는다.
PIRE0_EL1은 EL1(커널)에서만 쓸 수 있고, 변경 후 TLB flush가 필요하다. 권한을 바꾸려면 여전히 커널 진입이 불가피하다.

여기서 POE가 등장한다.

---

📝 Permission Overlay Extension (POE)

PIE로 base permission을 정했으면, 그 위에 overlay를 씌워서 EL0에서 직접 조이자!

POE (FEAT_S1POE)는 PIE가 결정한 base permission 위에 추가적인 제한(overlay) 을 EL0에서 직접, syscall 없이 걸 수 있는 기법이다.

POIndex: PIIndex와는 완전히 별개

POE는 PIE와 독립적인 별도의 index 공간을 사용한다.

	PIIndex	POIndex
PTE 비트 위치	UXN[54], PXN[53], DBM[51], USER[6] — 분산된 4비트	[62:60] — 연속된 3비트
비트 수	4-bit	3-bit
domain 수	16개	8개
lookup 레지스터	PIRE0_EL1 / PIR_EL1	POR_EL0 / POR_EL1
누가 수정	EL1 (커널)	EL0 (유저, syscall 없이!)

PIIndex와 POIndex는 서로 다른 PTE 비트를 사용하기 때문에, 하나의 PTE에 두 index가 동시에 존재한다.

POE의 8개 domain

POIndex는 3-bit이므로 0~7, 총 8개의 domain이다. 이 domain들은 PIE의 16개 domain과 별개의 공간이며, "어떤 실행 맥락(context)에서 허용할 권한" 을 정의한다.

POR_EL0:
[63:60] perm7 : r, w, x, po
[59:56] perm6 : r, w, x, po
[55:52] perm5 : r, w, x, po
[51:48] perm4 : r, w, x, po
[47:44] perm3 : r, w, x, po
[43:40] perm2 : r, w, x, po
[39:36] perm1 : r, w, x, po
[3:0]   perm0 : (고정: full permission, 호환성 보장)

domain 0는 full permission으로 고정되어 있어서 실질적으로 사용 가능한 overlay domain은 7개 (index 1~7) 다.

PIE + POE가 함께 동작하는 방식

두 extension이 모두 활성화된 경우, 권한 체인은 다음과 같다.

PTE[UXN,PXN,WRITE,USER] → PIRE0_EL1[PIIndex] → base_perm  (PIE가 결정)
                                                      ↓ AND
PTE[62:60]              → POR_EL0[POIndex]   → overlay_perm (POE가 추가 제한)
                                                      ↓
                                              effective_perm

overlay는 권한을 추가할 수 없고 제한만 가능하다. 또한 POR_EL0는 TLB에 캐싱되지 않으므로, 레지스터 write 한 번으로 즉시 effective permission이 바뀐다.

PIE 없이 POE만 활성화된 경우에는 기존 direct PTE permission이 base_perm이 된다.

---

📝 PIE + POE in your code

Kernel engineer

CONFIG_ARM64_POE=y   # ARMv8.9 architectural features 메뉴

PIE 초기화는 arch/arm64/mm/proc.S의 __cpu_setup에서:

mrs_s x1, SYS_ID_AA64MMFR3_EL1
ubfx  x1, x1, #ID_AA64MMFR3_EL1_S1PIE_SHIFT, #4
cbz   x1, .Lskip_indirection

mov_q x0, PIE_E0        // PIRE0_EL1 세팅
msr   REG_PIRE0_EL1, x0
mov_q x0, PIE_E1        // PIR_EL1 세팅
msr   REG_PIR_EL1, x0
mov   x0, TCR2_ELx_PIE
msr   REG_TCR2_EL1, x0  // PIE 활성화

POE context switch는 arch/arm64/kernel/process.c에서 POR_EL0를 per-task로 save/restore.
Linux 6.13-rc1부터 PIE + POE 모두 mainline 반영 완료.

Application engineer

POE는 Linux Memory Protection Keys (pkeys) syscall 인터페이스를 통해 노출된다.

// 1. protection key 할당 (커널이 POIndex를 할당)
int pkey = pkey_alloc(0, 0);

// 2. 메모리 영역에 pkey 연결 (PTE의 POIndex 비트를 설정, 커널 진입 필요)
pkey_mprotect(addr, len, PROT_READ | PROT_WRITE, pkey);

// 3. EL0에서 POR_EL0 직접 수정 — syscall 없음!
pkey_set(pkey, PKEY_DISABLE_WRITE);   // write overlay 제한
pkey_set(pkey, PKEY_DISABLE_ACCESS);  // read/write overlay 제한

// 4. 다시 허용
pkey_set(pkey, 0);

step 1~2는 커널 진입이 필요하지만, 권한을 자주 바꾸는 step 3~4는 순수 유저 공간에서 레지스터 write 한 번으로 끝난다는 게 핵심 이점.

---

📝 Security analysis

어디에 쓸 수 있나

PIE + POE의 핵심 타겟은 intra-process isolation이다.

• JIT runtime 격리: PIE로 JIT-compiled code 영역에 적절한 base permission을 부여하고, POE로 실행 맥락에 따라 접근 범위를 동적으로 좁힘
• Sandbox: 신뢰할 수 없는 third-party 라이브러리가 접근 가능한 메모리를 syscall 없이 실행 시점에 제한
• GCS 연동: PIE가 아니면 표현 자체가 불가능한 PIE_GCS permission을 통해 return address stack 보호

한계점

Domain 수 제한: POIndex가 3-bit이므로 실질적으로 7개 overlay domain만 사용 가능하다. PIE의 16개 domain과는 별개의 공간이고, 둘을 조합해서 늘릴 수는 있지만 (NanoZone 논문 참고) 그건 아키텍처 스펙 밖의 연구 레벨 기법이다.

intra-process 범위: POE는 프로세스 내 격리다. 커널이 타협되면 PIRE0_EL1 이나 PTE의 POIndex를 조작할 수 있다.

POR_EL0 무결성: POR_EL0는 EL0에서 직접 수정 가능하므로, 공격자가 임의 코드 실행 권한을 이미 획득했다면 overlay 설정을 바꿔버릴 수 있다. POE는 버그로 인한 의도치 않은 접근을 막는 데는 효과적이지만, 악의적인 코드의 의도적인 우회에 대해서는 별도 보호 레이어가 필요하다.

---

📝 Discussion

처음에 PIE 스펙만 봤을 때는 "PTE 비트를 index로 재활용하는 clever한 trick이구나" 정도였는데, domain 매핑 테이블을 직접 뜯어보니 설계 의도가 꽤 명확했다. 기존 16가지 PTE 비트 조합을 그대로 index로 재활용해서 하위 호환성을 유지하면서 GCS 같은 신규 permission type을 끼워 넣는 방식이 인상적이다. 특히 PAGE_GCS가 direct model에서는 모순적인 비트 조합이었던 걸 PIE로 유용하게 재탄생시킨 부분이 재미있다.

PIE와 POE의 역할 분담도 깔끔하다. PIE는 커널이 "이 페이지에는 어떤 permission을 줄 수 있는지"를 테이블로 정의하고, POE는 유저가 "지금 이 실행 맥락에서 그 중 얼마나 허용할 건지"를 레지스터로 실시간 조절하는 구조. 둘이 짝을 이뤄야 비로소 "표현력 있는 권한을 비용 없이 바꾸는" 게 완성된다.

다음에 나올 POE2 (FEAT_S1POE2)는 domain 수를 늘리고 caller context 기반 overlay까지 지원한다고 하니, 기대해볼 만 하다.

관련해서 PIE + POE를 ARM CCA 환경의 메모리 격리에 활용한 NanoZone 논문도 최근 나왔으니 관심 있다면 읽어볼 만 하다.