ARMv9 Realm과 CCA 구조

Realm의 정확한 의미

Realm은 일반 VM처럼 EL0+EL1에서 guest application과 kernel을 실행하는 격리 환경이다. Non-secure host kernel과 hypervisor는 Realm을 만들고, CPU 시간을 배정하고, 자원을 제공할 수 있다. 그러나 보호된 Realm의 코드·데이터·실행 register를 직접 읽거나 바꾸는 권한은 없다.

신뢰 경계: Realm은 host뿐 아니라 Secure World와 다른 Realm으로부터도 격리된다. Root World firmware와 RMM은 더 높은 신뢰 경계에 있으며, Realm 소유자는 attestation 결과로 실행 환경과 초기 상태를 검증한다.

4개 World와 실행 권한 구조

Physical Address Space, granule, GPT와 GPC

RME는 물리 메모리를 Non-secure PAS, Secure PAS, Realm PAS, Root PAS로 구분한다. 주소 변환이 숫자 PA를 계산한 뒤에도, 접근이 어느 PAS로 향하는지와 그 granule의 소유 상태가 맞아야 한다.

중요: Stage 2 page table을 host가 마음대로 바꿀 수 있다는 일반 VM의 가정은 Realm에 그대로 적용되지 않는다. Realm용 Stage 2와 보호 granule 상태는 RMM 경계를 거친다.

Host가 Realm 주소를 알아도 읽지 못하는 이유

금고의 위치를 안다고 열쇠가 생기는 것은 아니다. host는 Realm에 어느 physical page를 제공했는지 알고 스케줄도 할 수 있지만, 그 주소로 load를 실행하면 CPU의 마지막 보호 검사에서 막힌다.

page table permission이 read/write이고 TLB에 mapping이 있어도 결과는 달라지지 않는다. MMU permission은 “이 address space 안에서 이 virtual address를 사용할 수 있는가”를 묻고, GPC는 “이 World가 이 physical granule에 접근할 자격이 있는가”를 별도로 묻기 때문이다.

Arm의 Dynamic TrustZone 설명은 GPT가 4KB DRAM page의 World 할당을 기록하고 GPC가 Stage 1·2 검사에 추가로 매 접근을 검증한다고 설명한다.

RMM은 작은 전체 hypervisor가 아니다

Realm Management Monitor는 Realm 생성과 실행 context, Realm용 Stage 2 translation, 측정에 필요한 보호 상태를 관리한다. 장치 모델·일반 스케줄러·I/O backend 같은 전체 VMM 기능은 host 쪽에 남는다. 이 분리는 RMM의 신뢰 기반과 공격 표면을 줄이기 위한 구조다.

RMI, RSI와 Host Call

Realm이 실행되고 다시 Host로 나오는 과정

host가 Realm의 내부 register를 직접 채워 실행하는 구조가 아니다. host는 RMI로 “이 REC를 실행해 달라”고 RMM에 요청하고, RMM이 보호된 REC state를 CPU에 복원한다. Realm이 외부 서비스가 필요하거나 interrupt·fault가 생기면 RMM이 공개 가능한 exit 정보만 host에 돌려준다.

Host / KVM (NS-EL2)
    RMI_REC_ENTER(rec, run)
        ↓
RMM (R-EL2)
    host 입력 검증 → 보호된 REC register 복원 → Realm 진입
        ↓
Realm kernel (R-EL1)
    workload 실행 → host I/O가 필요하면 RSI_HOST_CALL
        ↓
RMM (R-EL2)
    보호 state 저장 → 공개 가능한 exit reason만 run 구조에 기록
        ↓
Host / KVM
    device emulation 또는 scheduling 후 다시 RMI_REC_ENTER

RSI는 Realm 안에서 RMM 서비스를 요청하는 방향이고, RMI는 host가 RMM을 관리하는 방향이다. Host Call은 Realm이 untrusted host service를 이용하는 통로이므로 반환값과 shared memory는 항상 공격자 입력으로 취급한다.

Realm 수명주기

1. Granule 위임: host가 사용할 RAM을 RMM 관리 경계로 넘길 준비를 한다.
2. RD 생성: Realm 속성, IPA 크기, hash 알고리즘 등 생성 조건을 고정한다.
3. RTT 구성: Realm의 IPA 공간과 보호·비보호 영역을 기술한다.
4. 초기 image 적재와 측정: 실행 전 코드·데이터를 보호 granule에 넣고 초기 측정값을 확장한다.
5. REC 생성: 초기 PC와 vCPU 실행 context를 준비한다.
6. 활성화: 초기 상태 변경을 닫고 실행 가능한 Realm으로 전환한다.
7. 실행과 exit: host가 REC를 실행하고, interrupt·host call·fault 등의 exit를 처리한다.
8. 파괴와 회수: REC·RTT·RD를 순서대로 제거하고 보호 정보를 지운 뒤 granule을 undelegate한다.

RMI 명령으로 보는 생성과 해체

아래는 RMM Architecture의 객체 관계를 이해하기 위한 대표 순서다. 실제 함수의 세부 인자와 허용 상태는 사용하는 RMM specification revision을 따라야 하지만, “위임 → 객체화 → 활성화 → 실행 → 역순 해체”라는 원칙은 변하지 않는다.

왜 역순인가: RTT가 아직 data를 가리키거나 RD가 REC를 소유한 상태에서 memory를 host에 반환하면 다른 사용자가 이전 Realm의 state를 보거나 RMM에 dangling reference가 남을 수 있다. 그래서 참조 관계를 끊고 내용을 정리한 뒤 undelegate한다.

Protected IPA와 Unprotected IPA

보호 IPA는 Realm 전용 코드·데이터를 담으며 host가 내용을 볼 수 없다. 비보호 IPA는 host와 I/O를 교환하기 위한 공유 영역이다. Realm은 공유 buffer를 공격자가 언제든 바꿀 수 있는 입력으로 취급해야 한다.

공유 buffer에서 생기는 TOCTOU 공격

Realm이 network packet을 host에 보내기 위해 비보호 page에 다음 descriptor를 놓았다고 하자. host는 이 page를 언제든 바꿀 수 있다.

// shared memory 안의 descriptor
struct request { uint64_t offset; uint64_t length; };

if (req->offset + req->length <= protected_buffer_size)
    encrypt(protected_buffer + req->offset, req->length);
// 검사 직후 host가 length를 큰 값으로 바꾸면 보호 영역 밖까지 읽을 수 있다.

struct request local = copy_from_shared(req);

if (local.offset > protected_buffer_size ||
    local.length > protected_buffer_size - local.offset)
    return ERROR;

encrypt(protected_buffer + local.offset, local.length);

Realm은 host를 “운영을 맡은 관리자”로는 이용하지만 “입력값을 믿을 보안 주체”로 보지 않는다. 이 구분이 일반 VM driver를 Realm에 그대로 가져오면 안 되는 가장 실질적인 이유다.

측정과 Attestation

Realm Initial Measurement는 생성 시점의 초기 image와 구성으로부터 만들어진다. 원격 검증자는 challenge를 보내 freshness를 확보하고, attestation token의 측정값·platform claims·공개키 연결을 검증한 뒤 비밀이나 workload를 제공할지 결정한다.

범위: attestation은 “이 초기 상태와 플랫폼에서 실행 중”이라는 근거다. 실행 후 application bug, side channel, 악성 입력까지 자동으로 제거하지 않는다.

검증자는 무엇을 비교하는가

1. 검증자가 보낸 새 challenge가 token에 결합돼 이전 token 재생이 막혔는지 확인한다.
2. platform token의 인증 경로와 lifecycle·security state가 허용 정책에 맞는지 확인한다.
3. Realm token의 초기 measurement가 승인한 kernel·initrd·설정의 기준값과 같은지 확인한다.
4. Realm 공개키나 workload identity가 token과 올바르게 결합됐는지 확인한 뒤에만 비밀을 전달한다.

측정은 hash만 같다고 끝나지 않는다. 누가 그 hash에 서명했는지, 검증 대상 platform이 취소되지 않았는지, challenge가 최신인지, debug가 허용됐는지를 policy로 판단해야 한다.

장치, 인터럽트와 DMA

virtual interrupt와 timer는 host scheduling과 Realm 실행을 연결한다. 그러나 장치가 보호 RAM에 DMA할 수 있게 하려면 CPU의 GPT만으로 충분하지 않다. SMMU, device security state, interrupt routing, reset·error handling과 attestation 정책이 같은 신뢰 경계에 들어와야 한다.

RME 버전별 확장

Linux/KVM에서 보는 경계

Linux host KVM은 Realm VM의 userspace 제어면과 scheduling을 제공하지만, 보호된 vCPU·memory state의 최종 관리자는 RMM이다. Linux guest는 RSI와 공유 I/O 경로를 사용하고, userspace VMM은 일반 VM과 다른 생성·measurement·attestation 순서를 따라야 한다.

Linux v6.18.37에서 실제로 구현된 Realm 경로

Architecture의 전체 Realm lifecycle과 현재 커널 tree의 구현 범위를 구분했다. 이 버전에는 Realm guest의 RSI 초기화·RIPAS·attestation 경로가 있지만, host KVM의 완전한 RME Realm 생성 경로는 들어 있지 않다.

Arm 공식 자료

• RMMRealm Management Monitor Architecture
• CCAUnlocking the power of data with Arm CCA
• RMEIntroducing Arm Dynamic TrustZone technology
• ArchitectureDDI 0487: A-profile Architecture Reference Manual