ARM 권한 모델 한눈에: EL0~EL3와 Armv9 Realm

🛡️ ARM Exception Level 완전 분석 — EL0부터 Armv9 Realm까지

Armv8-A·Armv9-A 권한 모델 | 앱부터 펌웨어, 그리고 클라우드 기밀 컴퓨팅까지

스마트폰 칩 하나 안에서 게임 앱과 운영체제 커널, 가상머신, 그리고 지문·암호키를 다루는 보안 코드가 동시에 돌아갑니다. 이들이 서로의 메모리를 훔쳐보지 못하게 막는 핵심 장치가 바로 ARM의 예외 수준(Exception Level, EL)입니다. 이 글은 EL의 4단계 권한 구조부터 32비트 시절과의 차이, 보안 세계 분리(TrustZone), 인터럽트가 어느 단계로 전달되는지, 레지스터는 어떻게 보존되는지, 그리고 Armv9이 새로 도입한 Realm(RME)까지 학습 곡선 순서대로 풀어냅니다.

📌 Exception Level이란 무엇인가

EL은 Armv8-A(AArch64)부터 도입된, 하드웨어가 강제하는 권한(Privilege) 계층입니다. 숫자가 클수록 더 높은 권한과 자원 접근권을 가집니다. 이름에 ‘예외(Exception)’가 붙은 이유는, 이 단계 사이의 이동이 오직 예외라는 하드웨어 이벤트로만 일어나기 때문입니다(뒤에서 자세히).

핵심만 추리면 앱=EL0, OS 커널=EL1, 하이퍼바이저=EL2, 보안 펌웨어=EL3입니다. 모든 레벨이 항상 필요한 건 아닙니다. 단순 임베디드는 EL0+EL1만 두기도 하고, 가상화·보안이 필요하면 EL2·EL3를 더합니다.

🔄 32비트의 옛 권한 모델은 왜 달랐나

AArch32(32비트)는 직관적인 수직 계층 대신 프로세서 모드(Processor Modes)라는 평면 구조를 썼습니다. 대표적인 7개 모드는 이렇습니다.

모드	역할
User	비특권 사용자 코드 (EL0에 대응)
FIQ / IRQ	빠른 인터럽트 / 일반 인터럽트 처리
Supervisor (SVC)	OS 커널, 리셋·SVC 명령 진입
Abort / Undefined	메모리 접근 오류 / 미정의 명령어 처리
System (SYS)	User와 같은 레지스터를 쓰되 특권을 가진 모드

여기에 가상화용 Hyp, 보안용 Monitor 모드가 나중에 더해졌습니다.

즉 AArch32에서 IRQ·Abort는 모드였지만, AArch64에서 IRQ는 모드가 아니라 “현재 EL에서 더 높거나 같은 타깃 EL로 가는 예외”일 뿐입니다. 옛 모드 개념이 EL + 예외 벡터로 흡수된 셈입니다.

🔐 Secure / Non-Secure — TrustZone의 두 세계

EL이 수직(권한) 축이라면, 보안 상태는 그와 직교하는 수평(격리) 축입니다. 이 두 축의 분리가 ARM 보안 모델을 이해하는 열쇠입니다. Armv8-A의 보안 기반인 TrustZone은 물리적으로 하나의 칩을 논리적으로 완전히 분리된 두 세계로 나눕니다.

규칙은 단순하고 강력합니다. Non-Secure 세계는 Secure 세계의 메모리·자원에 절대 접근할 수 없습니다. 두 세계 간 전환은 오직 최상위 EL3(Secure Monitor)를 거치며, SMC 명령으로만 가능합니다.

그래서 같은 EL1이라도 “Non-Secure EL1(일반 OS 커널)”과 “Secure EL1(보안 OS)”은 서로 다른 세계에 속한 별개의 실행 컨텍스트입니다. 결국 실제 실행 컨텍스트는 EL(권한) × Security State(세계)의 조합으로 결정됩니다.

⚡ EL을 넘나드는 메커니즘 — 마음대로 못 간다

EL 사이 이동은 코드가 임의로 할 수 없으며, 오직 하드웨어가 정의한 예외 발생(Taking)과 예외 복귀(Returning) 두 가지로만 가능합니다.

인터럽트가 들어오면 어느 EL로 가는가

외부 인터럽트(IRQ·FIQ)와 비동기 예외(SError)가 어느 EL로 전달(taken)되는지는, 신호가 코어에 도달했을 때 시스템 제어 레지스터 SCR_EL3와 HCR_EL2의 설정으로 결정됩니다. 절대 우선순위는 SCR_EL3가 HCR_EL2를 덮어쓴다(override)는 것입니다.

🔁 다이어그램 요약: 인터럽트 목적지는 두 비트가 순서대로 결정한다 — SCR_EL3의 IRQ 비트가 1이면 무조건 EL3(펌웨어)로, 0이면 HCR_EL2의 IMO 비트를 보고 1이면 EL2(하이퍼바이저), 둘 다 0이면 기본값 EL1(OS 커널)로 전달된다.

EL2로 가는 경우는 하이퍼바이저가 물리 인터럽트를 받아 가상 인터럽트(vIRQ·vFIQ)로 변환해 게스트 OS(EL1)에 주입하기 위함입니다. EL3로 가는 경우는 Trusted Firmware가 치명적 하드웨어 오류나 Secure Timer를 가로챌 때 쓰입니다.

“건너뛰기”의 정체 — 마스킹을 무시한다

프로세서가 특정 EL로 예외를 받으면 자동으로 PSTATE.DAIF 비트를 1로 세팅해 같은 종류 예외의 중첩을 막습니다(D=Debug, A=SError, I=IRQ, F=FIQ). 그런데 가장 중요한 규칙이 하나 있습니다.

💾 레지스터는 EL을 넘을 때 어디에 보관되나

“레지스터가 EL을 넘을 때 어떻게 보관되는가, EL별 별도 레지스터인가?” — 이 질문의 답은 32비트와 64비트가 철학을 완전히 바꿨다는 데 있습니다.

구분	AArch32 (옛 방식)	AArch64 (현재)
범용 레지스터	R8~R14를 모드별로 물리 복제(뱅킹)	X0~X30 전 EL 공유, 복제 안 함
진입 시 보존	별도 뱅크가 즉시 보임 → 빠름	하드웨어 자동 저장 없음 → SW가 직접 push
시스템 레지스터	모드별 일부 뱅킹	EL별 전용 _ELx 레지스터

AArch64는 범용 레지스터(X0~X30)를 복제하지 않고 모든 EL이 공유합니다. 그래서 예외 진입 시 하드웨어가 이를 자동 저장해 주지 않으며, 타깃 EL의 예외 핸들러(소프트웨어)가 직접 스택에 push 해 보존해야 합니다. 대신 EL별로 독립된 전용 시스템 레지스터를 제공하는데, 이름 끝의 _ELx 접미사가 그 레벨 전용임을 뜻합니다.

레지스터	역할	EL별 분리
SPSR_ELx	예외 직전 프로세서 상태(PSTATE) 백업	EL1/EL2/EL3
ELR_ELx	복귀할 PC(주소) 저장	EL1/EL2/EL3
SP_ELx	각 EL 전용 스택 포인터	EL0/EL1/EL2/EL3

예외 발생 시 하드웨어 동작 순서

정리하면, 상태·복귀·스택 레지스터는 EL별 전용이 맞고, 범용 레지스터는 공유라 소프트웨어가 직접 저장합니다. AArch32의 자동 뱅킹이 AArch64에서 “필수 시스템 레지스터만 전용 + 범용은 소프트웨어 저장”으로 깔끔하게 정리된 셈입니다.

🚀 Armv9-A의 신개념: Realm과 RME

왜 TrustZone만으로는 부족했나

기존 2분할 TrustZone은 칩 제조사가 Secure World를 통제하는 스마트폰 환경에서는 훌륭했습니다. 그러나 퍼블릭 클라우드 시대로 오며 한계가 드러났습니다. 클라우드 고객은 사업자(AWS·Azure 등)가 제공하는 하이퍼바이저(EL2)와 OS 위에서 VM을 돌립니다. 만약 사업자 관리자 권한이 탈취되거나 하이퍼바이저에 취약점이 생기면, 그 위 모든 고객 데이터가 노출되는 구조적 위험이 있었습니다.

이를 풀기 위한 개념이 기밀 컴퓨팅(Confidential Computing)이고, Armv9-A는 이를 하드웨어로 구현하기 위해 RME(Realm Management Extension)를 도입했습니다(Arm CCA). 핵심 전제는 “상호 불신(Mutual Distrust)” — 인프라 제공자(하이퍼바이저)조차 신뢰하지 않고, 데이터 소유자만 접근 가능한 절대 격리 공간을 만든다는 것입니다.

보안 상태가 2분할 → 4분할로

RME 도입으로 보안 상태가 2개에서 4개로 확장되었고, 이는 물리 주소 공간 자체가 4개로 분할됨을 의미합니다.

가장 큰 변화는 EL3의 역할 격상입니다. 기존 EL3는 Secure State에 속했으나, RME에서는 모든 상태의 최상위 게이트키퍼인 Root State로 올라갑니다.

작동 방식과 장점

경쟁 기술과의 비교 — Intel·AMD와의 3파전

항목	Arm CCA (RME)	Intel TDX	AMD SEV-SNP
격리 핵심	작고 검증 가능한 모니터 RMM + HW RME, 시스템 버스·I/O까지 그래뉼 보호 지향	격리된 SEAM 모드의 TDX 모듈	AMD Secure Processor가 메모리 암호화 키·Nested Paging 무결성 관리
신뢰 의존	상대적으로 작은 모니터 + 하드웨어	마이크로코드 / 펌웨어	Secure Processor 펌웨어

성능 오버헤드 — 워크로드가 결정한다

모든 기밀 컴퓨팅 플랫폼은 무엇을 돌리느냐에 따라 비용 편차가 큽니다. CPU·메모리 안에서 끝나는 연산은 거의 공짜에 가깝지만, 디스크·네트워크를 자주 드나드는 I/O 집약 작업은 암복호화와 잦은 문맥 교환으로 무거워집니다.

일부 I/O 시나리오에서는 14~56%의 패널티가 보고되며, Realm VM과 RMM 사이의 통신이 명령어 수준의 적지 않은 오버헤드를 유발한다고 지적됩니다(모바일·엣지에서 암호화를 우회하는 PORTAL 같은 연구도 제안됨).

채택 현황

하드웨어 측면에서는 RME를 완전 지원하는 상용 실리콘이 아직 널리 풀리지 않아, 개발·연구는 주로 Arm FVP(Fixed Virtual Platform) 에뮬레이터, 프로토타입 보드, Islet·OpenCCA 같은 오픈소스에 의존합니다. 소프트웨어 측면에서는 2024년 9월 RMM 1.0 Specification(REL0)이 최종 릴리즈됐고, TF-A·TF-RMM 레퍼런스 코드가 Linux 커널·KVM에 업스트림되기 시작했습니다. 향후 하드웨어가 보급되면 “lift-and-shift”로 즉시 전환할 기반을 다지는 시기인 셈입니다.

※ 위 성능 패널티 범위와 RMM 1.0 릴리즈 시점 등 현황 수치는 2024년 하반기 ARM 레퍼런스·관련 논문·커널 패치를 근거로 한 것이며, 상용 하드웨어 보급 상황은 빠르게 변할 수 있어 최신 확인이 필요합니다.

🎯 정리 — 권한 × 격리, 두 축으로 보는 ARM 보안

ARM의 권한 제어 모델은 디바이스 중심 → 클라우드 중심 컴퓨팅으로의 진화를 그대로 반영합니다.

한 줄 학습 지도: EL(권한 4단계) → AArch32 모드와의 차이 → Secure/Non-Secure(격리 축) → 예외·인터럽트로만 EL 이동 → 레지스터는 시스템 전용 + 범용 공유 → Armv9 Realm으로 격리 축이 4분할로 확장. 이 흐름을 따라가면 “권한(수직) × 격리(수평)”라는 ARM 보안 모델의 두 축이 자연스럽게 잡힙니다.