TETD: Trusted Execution in Trusted Domains

• Usenix Security ‘25 발표 논문
• 논문 링크

Motivation

CVM (Confidential Virtual Machine)

기존 퍼블릭 클라우드 환경에서 테넌트들은 자신의 데이터와 워크로드를 관리하는 CSP (Cloud Service Provider) 를 전적으로 신뢰해야만 했습니다. 하지만 클라우드 인프라를 제어하는 하이퍼바이저나 호스트 OS가 공격자에 의해 손상당하거나 악의적인 접근이 발생할 경우, 사용자의 데이터와 실행 상태가 노출될 위험이 존재합니다.

이러한 근본적인 보안 문제를 해결하기 위해 등장한 기술이 CVM입니다. CVM은 잠재적으로 신뢰할 수 없는 하이퍼바이저 및 호스트 OS로부터 클라우드 서비스 기반 워크로드를 보호하도록 설계된 환경입니다. 즉 CSP 조차도 사용자의 가상 머신 내부에 접근할 수 없도록 물리적인 보안 경계를 형성하여 제공합니다.

CVM은 아래와 같은 하드웨어 수준의 지원을 통해 구현됩니다.

• 하드웨어 기반 메모리 암호화 및 격리: TDX로 예를 들면, 추가적인 CPU 실행 모드인 SEAM mode와 메모리 암호화 (Total Memory Encryption) 기술을 활용하여 VMM을 포함한 외부의 어떤 시스템 소프트웨어도 CVM 내부의 데이터를 평문으로 읽거나 변조할 수 없도록 차단합니다.
• 원격 증명 (Remote Attestation): 부팅 시점에 원격 증명 기능을 제공하여, 클라우드 사용자가 자신이 실행하려는 런타임 환경과 비밀 키 등의 무결성이 훼손되지 않았음을 직접 검증할 수 있게 해줍니다.

현재 이 기술을 상용화한 대표적인 하드웨어 구현체로는 인텔의 TDX (Trust Domain Extensions) 와 AMD의 SEV-SNP가 있습니다.

참고: TD (Trust Domain) 는 Intel TDX에서 CVM을 지칭하는 용어입니다.

Core Problems

이 논문에서 해결하고자 하는 근본적인 문제는 다음 세 가지 측면으로 요약할 수 있습니다.

1. CVM의 하드웨어적 격리로 인한 Introspection의 부재
   일반적인 가상 머신 환경에서는 VMM (Virtual Machine Monitor) 이 게스트의 메모리와 vCPU 컨텍스트에 제약 없이 접근할 수 있어서 VM Introspection (실행중인 VM의 내부 상태를 외부에서 실시간으로 모니터링하고 분석하는 기술) 과 같은 관리 작업이 가능했습니다. 그러나 CVM 에서는 하드웨어 기반의 격리를 통해 VMM의 접근을 차단합니다. 이러한 아키텍처는 CSP로부터 데이터를 보호하지만, 역설적으로 정당하고 필수적인 가상 머신의 Introspection 작업까지 불가능하게 만듭니다.
2. 게스트 커널 손상 시 보안 통제권의 상실
   CVM 환경에서 가장 치명적인 문제는 TD 내부의 게스트 커널이 내부 공격자 등에 의해 손상되었을 때 발생합니다. 이 경우 CSP나 TD의 소유자는 런타임 환경에 접근할 수 있는 수단이 없기 때문에 해당 TD에 대한 모든 보안 통제권을 상실하게 됩니다.
3. Privilege Layering (기존 해결책) 의 구조적 한계
   기존에는 이 문제를 해결하기 위해 Introspection Agent를 CVM 커널보더 다 높은 권한 수준에 배치하는 Privilege Layering 방식이 제시되었습니다. 하지만 이 접근법은 가장 높은 권한을 가진 소프트웨어의 크기를 키워 TCB를 확장시키며, 결과적으로 CVM 전체의 보안을 약화시킵니다. 또한 가장 높은 권한의 에이전트는 공격의 Single-point of failure가 되며, 권한 계층 간의 컨텍스트 switch로 인한 지속적인 성능 오버헤드를 유발합니다.

요약하자면 이 논문이 해결하고자 하는 핵심 문제는 CVM의 보호 매커니즘이 외부 위협으로부터 시스템을 방어하지만, 가장 높은 권한을 가진 내부 시스템 소프트웨어가 손상되었을 때는 대응할 수 있는 방법이 사라진다는 구조적인 딜레마입니다.

Challenges

위에서 알아본 문제의 어려운 점은 먼저 TD의 외부 환경에서는 Introspection Agent를 구현할 수 없다는 점입니다. CVM의 기본적인 보안 개념을 유지하기 위해 런타임 데이터를 신뢰할 수 없는 VMM에 노출할 수 없습니다. 또한 TD 내부에서는 Intel SGX 엔클레이브와 같은 Trusted Execution Environment를 지원하지 않습니다. 즉 손상된 커널로부터 내부 소프트웨어를 보호할 수 있는 네이티브 지원이 존재하지 않습니다. 또한 TDX 모듈은 인텔이 TCB로서 관리하기 때문에 TD 내부 접근 권한을 얻기 위해 TDX 모듈 자체를 임의로 수정하는 접근법은 배제되어야 합니다.

저자들은 기존의 Privilege Layering 기법과 같이 TCB를 비대하게 만들거나 단일 장애점이 되지 않으면서도 문제를 해결하는 방법을 고안하고자 했습니다. 결과적으로 VMM이 이미 가지고 있는 기본적인 리소스 관리 기능 (vCPU 스케줄링 및 메모리 blocking) 만을 활용하여 Resource Separation을 하는 Approach를 선택했습니다.

TDX architecture

인텔 TDX는 하드웨어 수준의 Trusted Boundary를 형성하기 위해 CPU의 동작 모드를 물리적으로 분리했습니다.

• Non-SEAM: 기존의 호스트 VMM이 실행되는 영역입니다. 이 모드에서는 CVM의 프라이빗 메모리와 vCPU 컨텍스트에 접근하는 것이 차단됩니다. VMM은 오직 게스트에 대한 물리적 자원의 스케줄링과 배분 권한만 가집니다.
• SEAM (SEcure Arbitration Mode): TDX 아키텍처의 하드웨어 격리 모드로, 암호화된 CVM인 TD와 이를 관리하는 TDX 모듈이 이 모드 내에서 실행됩니다.

Non-SEAM과 SEAM 간에는 하드웨어적으로 정의된 특수 명령어를 사용합니다. SEAMCALL은 non-privileged 영역인 Non-SEAM의 VMM이 SEAM의 TDX 모듈에 TD 생성, vCPU 할당, 메모리 block 등의 자원 관리 작업을 요청할 때 호출하는 명령어입니다. TDCALL은 SEAM 내의 TD 게스트가 TDX 모듈의 물리 자원 관리 기능을 간접 호출할 때 사용하는 명령어입니다. VMCALL은 TDCALL 인터페이스의 일종으로, TD 게스트가 하이퍼바이저 VMM에 I/O 요청 등 외부 서비스 처리를 위임하기 위해 사용합니다.

다음으로 TETD에서 주로 사용하는 TDX의 Resource Management Primitive들에 대해 알아보겠습니다.

TD의 게스트 물리 주소 (GPA) 공간은 독점 영역인 프라이빗 페이지와 외부 I/O 장치 등과 데이터 교환을 위한 shared 페이지로 분리됩니다. TDX 모듈은 TD마다 하나의 SEPT (Secure Extended Page Table) 를 빌드하여 프라이빗 주소 변환 (GPA to HPA) 을 안전하게 수행합니다. VMM은 SEPT의 물리 페이지 자체는 공급하지만, 주소 매핑 구조를 임의로 변경하거나 권한 비트를 조작할 수 없습니다. VMM은 이러한 GPA to HPA 주소 변환을 강제로 중단하는 GPA Blocking Primitive (TDH.MEM.RANGE.BLOCK) 및 TLB 오염을 방지하는 TLB Tracking 매커니즘을 제공하고 있습니다.

호스트의 각 물리 코어 스레드는 물리 프로세서 (Logical Processor, LB) 로 취급됩니다. VMM은 TDH.VP.ENTER 명령을 통해 특정 LP에 TD vCPU를 바인딩하고 실행 시간을 할당하는 역할을 수행할 수 있습니다. 그러나 VMM은 연산 장치의 시작과 종료 스케줄링만을 제어하며 임의로 실행 중인 프로세서 내부의 레지스터 상태나 컨텍스트를 읽고 변조할 수 없습니다.

TETD Design

High Level Idea

TETD의 아이디어는 Resource Separation을 통해 TD 내부에 독립적인 subsystem (agent) 을 만드는 것입니다. 즉 VMM의 기존 리소스 관리 기능을 이용해 에이전트의 컴퓨팅 리소스를 TD 시스템 소프트웨어로부터 격리합니다.

에이전트는 두가지 실행 상태 (active/rest) 를 가지며 실행 상태에 따라 resource management primitive를 적용합니다. 먼저 rest 상태일 때는 에이전트를 향한 메모리 접근에 대해 GPA Blocking 기능을 사용하여 TD를 포함한 다른 모든 외부로부터의 메모리 접근을 차단하고, 에이전트의 vCPU가 스케줄링되지 않도록 설정합니다. active 상태에서는 GPA Blocking을 해제하고, vCPU가 스케줄링되도록 하여 작업을 수행합니다.

또한 TETD는 사용 목적에 맞춰 두 가지 형태의 에이전트 모드를 지원합니다

• Exclusive Mode: 에이전트가 실행되는 동안 TETD의 vCPU 스케줄링 제어를 통해 다른 모든 TD 스레드의 실행이 일시 중지됩니다. 시스템이 정지된 상태에서 에이전트가 동작하므로, VM Introspection과 같은 TD 단위 서비스에 사용할 수 있습니다.

• Collaborative Mode: 에이전트가 다른 신뢰할 수 없는 TD 스레드와 동시에 실행되며 상호작용할 수 있습니다. 이 모드에서는 전체 TD를 멈추거나 GPA Blocking을 사용하지 않으며 52-bit GPA 공간에서 무작위로 할당된 secret location에 에이전트를 배치하여 런타임 추측 공격으로부터 에이전트를 안전하게 실행할 수 있도록 합니다.

Implementation

TETD의 실제 구현은 호스트 레벨의 TETD-H와 게스트 레벨의 TETD-G로 나뉘어 설계되었습니다.

1. TETD-H (Host-level Component)
   TETD-H는 리눅스 KVM 코드스페이스 내에 약 823줄의 C코드로 직접 구현되었습니다. 호스트 측에서 에이전트의 물리적 자원과 상태를 통제하는 역할을 수행하며, 구체적인 설계는 다음과 같습니다.

   • 8개의 VMCALL 핸들러: GPA selection, 에이전트 활성화, Worksite Relocation 등을 처리하기 위한 API들을 제공합니다 (자세한 API 목록은 논문의 Appendix A를 참고하세요). 이 VMCALL들은 게스트에서 TDCALL을 호출할 때 RAX 레지스터의 하위 비트(15:0)를 VMCALL 타입으로 지정하여 호스트 VMM으로 전달하며, R10 레지스터로 VMCALL 번호를, R11-R14 레지스터로 파라미터를 수신합니다.

   • 물리 페이지 관리 및 가비지 컬렉션 (Physical Pages Handling): 에이전트에 사용되는 물리 메모리 페이지는 Intel TDX의 private page 요구사항을 준수해야 하므로, SGX 엔클레이브와 동일하게 CMR(Core Memory Region) 내에 위치해야 합니다. TETD-H는 이러한 할당 페이지들을 메타데이터 테이블(Table 6)을 통해 직접 추적하고 제어합니다. TD 가상머신이 destroy 될 때 QEMU 프로세스에 직접 매핑되지 않은 이러한 특수 페이지들이 leak 되는 것을 막기 위해 TETD-H는 정기적으로 실행되는 가비지 컬렉터를 포함하여 활성 상태를 모니터링하고 사용이 끝난 에이전트 페이지들을 호스트 OS로 회수합니다.

   • #VE Suppression: 게스트 TD가 존재하지 않거나 매핑되지 않은 물리 주소(GPA)에 접근할 때, 하드웨어적으로 #VE (Virtualization Exception, 게스트가 자체 처리) 혹은 EPT-violation (VM Exit이 발생하여 VMM이 처리)이 발생할 수 있습니다. Collaborative Mode에서 공격자가 에이전트의 secret worksite를 추측하여 접근을 시도할 때, 이 악의적인 동작이 게스트 내부 #VE 핸들러에 의해 VMM 모르게 무마되는 것을 완전히 차단해야 합니다. 따라서 TETD는 VMCS(Virtual Machine Control Structure) 설정을 전역적으로 수정하여 TD 전체의 #VE를 강제로 억제(Suppress)합니다. 이를 통해 무단 메모리 접근 시도가 EPT-violation을 유발하여 호스트 TETD-H로 제어권이 넘어오게 하고, 즉각적인 worksite relocation(재배치) 트리거로 연결되도록 설계했습니다.

 
2. TETD-G (Guest-level Component)
TETD-G는 게스트 레벨에서 페이징 관리와 같은 시스템적 작업을 처리하고 에이전트와 호스트 TETD-H 간의 통신을 중개하는 역할을 합니다. 최소한의 stub 에이전트를 포함해 약 1,637줄의 C코드로 구현되었으며, 게스트 내에서 약 0.2MB의 극소량 메모리만을 점유합니다.

TETD-G는 다음과 같은 4가지 핵심 서브컴포넌트로 구성됩니다.

• Agent SDK: 에이전트와 함께 정적으로 컴파일되는 라이브러리로, 에이전트 개발자가 자신의 워크플로우를 단계별로 설계할 수 있게 지원합니다. init 호출을 통해 에이전트 부팅 시 실행될 초기화 함수 포인터를 등록하고, ret 인터페이스를 통해 작업 완료 후 안전하게 종료를 유도합니다. VMM 단에서의 데이터 도청을 방지하기 위해 TETD-G는 에이전트로 들어오고 나가는 인자 및 리턴값들을 대칭키로 양방향 암호화합니다.

• Agent Environment: 에이전트가 손상된 게스트 커널을 신뢰하지 않고 독자적으로 실행될 수 있도록 돕는 일종의 ‘미니 OS’ 역할을 합니다. 에이전트 부팅 시 프라이빗 메모리 영역 내에 완전히 독립된 스택, 게스트 페이지 테이블(Guest Page Table), IDT(Interrupt Descriptor Table), GDT(Global Descriptor Table)를 빌드합니다. 특히 페이지 테이블 생성 시, 게스트 커널 영역의 GPA들을 매핑해두되 해당 페이지들의 실행 권한을 제거하여 임의의 커널 코드 호출을 통한 공격을 격리합니다.

• TDCALL Wrapper: 어셈블리 명령어를 C 언어 심(Shim)과 결합한 래퍼 라이브러리입니다. 레지스터를 통해 전달되는 각 파라미터들의 패킹 및 언패킹 작업을 도맡아 수행하며, 고수준의 C API와 어셈블리 단의 하드웨어 명령어 간의 트랜지션을 처리합니다.

• Agent Encapsulation: TETD-G와 에이전트는 시스템 부팅 중에 자동으로 로드되는 리눅스 커널 모듈(LKM) 형태로 빌드되어 게스트의 extra modules 디렉토리에 설치됩니다. 부팅 시퀀스의 올바른 타이밍에 맞춰 자동으로 구동될 수 있도록 custom systemd 서비스 유닛을 활용해 부팅 workflow에 통합됩니다.

Evaluation

TETD 프로토타입의 평가는 Intel Xeon Silver 4510 프로세서 (24 물리 코어) 및 512GB RAM을 탑재한 Ubuntu 24.04 LTS 호스트 서버 환경에서 수행되었습니다. 게스트 TD 가상머신은 16 vCPU, 2GB RAM 사양으로 구성되었습니다.

1. TETD Hardware Primitives

먼저 TETD 동작에 관여하는 주요 SEAMCALL 및 TDCALL 명령어들의 기본 오버헤드(호출 후 반환까지 소요되는 총 시간)를 측정한 결과는 다음과 같습니다.

2. Agent State Transition (128 KB Dummy Payload)

에이전트가 Exclusive Mode와 Collaborative Mode에서 각각 동작할 때의 초기화 및 런타임 1회 라운드 실행 오버헤드는 다음과 같은 차이를 보입니다.

• Exclusive Mode는 에이전트 실행 시 다른 vCPU들을 중지시키고 GPA 영역을 강제로 block/unblock해야 하므로 약 312.6 µs의 비교적 높은 런타임 오버헤드가 발생합니다.
• 반면, Collaborative Mode는 리소스 blocking 작업이 생략되므로 단 42.4 µs만에 동작 전환이 완료됩니다. 단, 이 모드는 주기적인 재배치(Relocation) 오버헤드가 발생합니다.

3. Worksite Relocation

Collaborative Mode 에이전트의 물리적 위치(GPA)를 무작위로 이동시켜 공격을 방지하는 Worksite Relocation 오버헤드는 보호하려는 에이전트의 메모리 크기에 따라 선형적으로 증가합니다.

참고: 2MB의 데이터를 단순히 메모리 카피하는 데 약 680 µs가 소요됨을 감안할 때, SEPT 갱신 및 암호화 페이지 할당 등 추가 보안 메커니즘을 포함한 916 µs는 상대적으로 효율적인 수치입니다.

4. Whole TD System Performance

TETD가 일반적인 가상머신 워크로드에 미치는 실질적인 성능 저하를 Apache 벤치마크 처리량 및 LMbench를 통해 테스트했습니다.

• Exclusive Mode의 경우, 초당 100회 빈도로 에이전트를 활성화하여 전체 TD를 정지시킬 경우 약 6.8%의 뚜렷한 성능 하락이 발생했습니다. 따라서 Exclusive Mode 에이전트는 빈번한 상호작용보다는 일회성 서비스(VM Introspection 등)에 더 적합합니다.
• Collaborative Mode는 에이전트의 크기가 16 KB에서 4 MB로 급증해도 성능 하락 폭이 거의 평탄하게 유지되어 훨씬 뛰어난 확장성(Scalability)을 보여주었습니다.

Wrap Up

Discussion

1. Detectability
   게스트 커널 수준의 공격자는 커널이 실제로 사용할 수 있는 가상 CPU의 개수와 시스템 상의 NUM_VCPUS 사이에 발생하는 불일치를 관찰함으로써 TETD의 존재를 탐지할 수 있습니다. 그러나 공격자가 TETD의 존재를 인지하게 되면, 프레임워크 내부의 방어 메커니즘이 트리거되는 것을 피하기 위해 악의적인 행위 자체를 자제하는 방어 효과를 기대할 수도 있습니다.
2. Compatibility
   TETD가 제안하는 Resource Separation 아키텍처는 Intel TDX 플랫폼에만 종속되지 않으며 타 아키텍처로의 확장성을 열어두고 있습니다. 예를 들어 ARM CCA 환경에서 Realm Management Monitor를 수정하여 TETD 아키텍처를 적용시킬 수 있을 것입니다. 또한 향후 구현에서는 TETD의 작업들을 효율적으로 지원하기 위해 TD partitioning과 같은 TDX native 기능을 접목할 수 있는 가능성이 존재합니다.
3. VMM Security
   현재 TETD 메커니즘은 기본적으로 호스트 VMM이 변조되지 않고 올바르게 작동한다는 전제를 바탕으로 설계되었습니다. 따라서 가상 머신이 실행되는 런타임 도중에 VMM의 compromise를 탐지하는 것은 여전히 해결해야 할 과제로 남아 있습니다.

Conclusion

TETD (Trusted Execution in Trusted Domains) 논문은 가상화 수준의 격리를 제공하는 CVM 환경에서 역설적으로 “가장 권한이 높은 게스트 커널이 침해되었을 때 대처할 방안이 없다"는 딜레마를 풀어냈습니다.

인텔 TDX 모듈의 하드웨어 명세를 변경하거나 TCB를 과도하게 키우는 기존의 Privilege-Layering 설계 방식에서 벗어나, VMM의 기존 물리 리소스 관리 Primitive (vCPU 스케줄링 및 GPA Blocking/relocation)를 응용하여 에이전트를 완전히 분리하는 Resource-Separation 접근법을 사용했습니다.

결과적으로 Intel TDX가 하드웨어 수준에서 제공하는 근본적인 가상화 원칙을 깨뜨리지 않으면서도 시스템 내부에 에이전트를 안전하게 호스팅할 수 있는 실질적인 솔루션을 제안했습니다.

Critique

TETD 프레임워크가 가진 격리 능력에도 불구하고 몇 가지 명확한 한계점과 개선 과제가 있습니다.

• VMM compromise 시 방어 부재: 호스트 VMM 자체가 완전히 장악되었을 때 이를 방어할 수 있는 자체적인 보안 메커니즘이 아직 부족합니다.
• 워크로드 검증 범위의 제한: 현재 구현된 초기 프로토타입은 에이전트에 대한 멀티스레딩 아키텍처를 지원하지 않습니다. 이로 인해 실제 대규모 서비스 환경에서 요구되는 high-concurrent 환경이나,Compute-intensive한 실제 클라우드 워크로드를 대상으로 한 대규모 성능 평가는 아직 이루어지지 않았다는 한계가 존재합니다.