기밀 컴퓨팅 (Confidential Computing)

사용 중인 데이터(data-in-use)를 하드웨어 기반으로 보호하는 기밀 컴퓨팅(Confidential Computing) 기술을 심층 분석합니다. AMD SEV/SEV-ES/SEV-SNP, Intel TDX, ARM CCA/Realm의 아키텍처 설계와 리눅스 커널 통합을 비교하고, 메모리 암호화(Encryption) 엔진, 원격 증명(Remote Attestation), SVSM, KVM fd-based private memory(gmem), virtio bounce buffer, 기밀 컨테이너(Kata/CoCo), GPU TEE까지 포괄합니다.

위협 모델

기밀 컴퓨팅의 위협 모델은 전통적 보안 모델과 근본적으로 다릅니다. 하이퍼바이저, 호스트 OS, 물리적 접근을 가진 관리자까지 비신뢰(untrusted)로 분류합니다. 이는 멀티테넌트 클라우드 환경에서 특히 중요합니다: 테넌트는 CSP의 인프라를 신뢰하지 않고도, 자신의 워크로드가 안전하게 실행되고 있음을 하드웨어 기반 증명으로 확인할 수 있습니다.

전통적 클라우드 보안에서는 CSP가 제공하는 소프트웨어 격리(가상화, 컨테이너)를 신뢰해야 합니다. 하지만 CSP의 관리자, 내부 공격자, 법적 강제(영장)에 의해 데이터가 노출될 위험이 있습니다. 기밀 컴퓨팅은 이 신뢰 관계를 하드웨어로 대체합니다.

위협 모델 범위

사이드 채널 공격과 기밀 컴퓨팅

기밀 컴퓨팅의 위협 모델에서 사이드 채널 공격은 "부분적 보호"로 분류됩니다. 일부 공격은 하드웨어 수준에서 완화되지만, 다른 공격은 소프트웨어 방어가 필요합니다.

TCB 크기 비교

메모리 암호화 엔진

기밀 컴퓨팅의 기반은 하드웨어 메모리 암호화입니다. CPU 내부의 메모리 컨트롤러에 AES 엔진이 통합되어, 모든 DRAM 트래픽을 실시간(Real-time)으로 암호화/복호화(Decryption)합니다. 이 암호화는 CPU 캐시(L1/L2/L3) 이후에 적용되므로, 캐시 내부의 데이터는 평문으로 유지되어 성능 영향이 최소화됩니다. 즉, CPU에서 메모리 컨트롤러로 나가는 시점에서만 AES 변환이 일어납니다.

AMD SME (Secure Memory Encryption)

SME는 AMD EPYC 1세대(Naples)부터 도입된 투명 메모리 암호화입니다. 물리 주소(Physical Address)의 C-bit(bit 47)이 1이면 해당 페이지(Page)를 AES 엔진이 암호화합니다. SME는 SEV의 기반 기술이지만, 독립적으로도 사용 가능합니다: 비가상화 환경에서도 cold-boot 공격을 방어합니다.

/* arch/x86/mm/mem_encrypt_amd.c — SME 초기화 */
void __init sme_enable(struct boot_params *bp)
{
    unsigned long me_mask;

    /* CPUID Fn8000_001F[EAX] bit 0 = SME 지원 */
    if (!(cpuid_eax(0x8000001f) & BIT(0)))
        return;

    /* C-bit 위치 = CPUID Fn8000_001F[EBX] bits 5:0 */
    me_mask = 1UL << (cpuid_ebx(0x8000001f) & 0x3f);
    sme_me_mask = me_mask;

    /* MSR_AMD64_SYSCFG의 MEM_ENCRYPT 비트 활성화 */
    wrmsrl(MSR_AMD64_SYSCFG,
           rdmsrl(MSR_AMD64_SYSCFG) | MSR_AMD64_SYSCFG_MEM_ENCRYPT);
}

Intel TME/MKTME

TME(Total Memory Encryption)는 전체 메모리를 단일 키로 암호화하고, MKTME(Multi-Key TME)는 최대 64~256개의 키를 지원합니다. TDX에서는 HKID(Host Key ID)를 통해 TD별 키를 자동 관리합니다. TME와 MKTME는 독립적으로 사용할 수도 있지만, TDX는 MKTME를 필수로 활용합니다.

/* arch/x86/virt/vmx/tdx/tdx.c — MKTME KeyID 범위 확인 */
static int __init tdx_init(void)
{
    u32 eax, ebx, ecx, edx;

    /* CPUID.19H — TME 관련 정보 */
    cpuid_count(0x1b, 0, &eax, &ebx, &ecx, &edx);

    /* TDX가 사용할 수 있는 private HKID 범위 */
    tdx_global_keyid = ecx;
    nr_tdx_keyids = edx;

    pr_info("TDX: %u private KeyIDs available\n", nr_tdx_keyids);
    return 0;
}

암호화 키 관리 구조

AES-XTS 동작 원리

/* AES-XTS 암호화 (개념 코드) */
/* 물리 주소를 tweak 값으로 사용하여 위치 종속 암호화 */
void aes_xts_encrypt_block(
    u8 *plaintext,       /* 16바이트 평문 블록 */
    u8 *ciphertext,      /* 16바이트 암호문 블록 */
    u8 *key1,            /* 데이터 암호화 키 */
    u8 *key2,            /* tweak 암호화 키 */
    u64 physical_address) /* tweak 입력: 물리 주소 */
{
    u8 tweak[16];

    /* 1단계: tweak 계산 — 물리 주소를 key2로 암호화 */
    aes_encrypt(key2, &physical_address, tweak);

    /* 2단계: 평문 XOR tweak */
    xor_block(plaintext, tweak, temp);

    /* 3단계: AES 암호화 */
    aes_encrypt(key1, temp, temp);

    /* 4단계: 암호문 XOR tweak */
    xor_block(temp, tweak, ciphertext);

    /* 결과: 같은 평문도 다른 물리 주소에서는 다른 암호문 생성 */
    /* → 데이터 이동/복제 공격 방어 */
}

AMD SEV 개요

AMD SEV(Secure Encrypted Virtualization)는 AMD-V 가상화 확장에 하드웨어 메모리 암호화를 결합한 기술입니다. 2016년 AMD EPYC 1세대(Naples)에서 처음 도입되었으며, 이후 ES(Encrypted State)와 SNP(Secure Nested Paging)를 거쳐 발전해왔습니다. PSP(Platform Security Processor, ARM Cortex-A5 기반)가 키 관리와 보안 정책을 담당합니다. SEV 시리즈는 현재 가장 성숙한 기밀 컴퓨팅 플랫폼으로, 주요 CSP(Azure, GCP, OCI)에서 프로덕션 서비스로 운영되고 있습니다.

PSP (Platform Security Processor)

PSP(Platform Security Processor)는 AMD SoC에 통합된 ARM Cortex-A5 기반 보안 프로세서입니다. 메인 CPU와 물리적으로 분리된 독립 실행 환경에서 SEV 펌웨어를 실행하며, 키 생성/관리, 증명 보고서 서명, 게스트 시작/종료 프로토콜을 처리합니다. PSP는 SoC 부팅 시 가장 먼저 초기화되며, 메인 CPU보다 먼저 보안 상태를 설정합니다. Linux에서는 CCP(Cryptographic Co-Processor) 드라이버를 통해 PSP와 통신합니다.

/* drivers/crypto/ccp/sev-dev.c — PSP 명령 전송 */
static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
{
    struct psp_device *psp = psp_master;
    unsigned int reg;

    /* 명령 + 물리 주소를 PSP 메일박스에 기록 */
    iowrite32(__pa(data), psp->io_regs + psp->vdata->cmdbuff_addr_lo_reg);
    iowrite32(cmd, psp->io_regs + psp->vdata->cmdresp_reg);

    /* PSP 응답 대기 */
    wait_for_completion(&psp->sev_data->cmd_complete);

    reg = ioread32(psp->io_regs + psp->vdata->cmdresp_reg);
    if (psp_ret)
        *psp_ret = FIELD_GET(PSP_CMDRESP_STS, reg);

    return FIELD_GET(PSP_CMDRESP_STS, reg) ? -EIO : 0;
}

SEV 아키텍처 확장 (Zen 세대별)

ASID 기반 키 격리

각 SEV VM에는 고유한 ASID(Address Space ID)가 할당되며, AES 엔진은 ASID를 참조하여 해당 VM의 암호화 키를 선택합니다. ASID 범위는 CPUID Fn8000_001F[ECX]로 확인합니다.

# SEV 지원 확인
dmesg | grep -i sev
# 출력 예: ccp 0000:22:00.1: sev enabled
#          SEV: 509 ASIDs, SEV-ES: 100 ASIDs

# SEV 펌웨어 버전 확인
cat /sys/devices/virtual/misc/sev/fw_version
# 출력 예: 1.55.24

# 사용 가능한 SEV ASID 수
cat /sys/devices/virtual/misc/sev/asids

SEV-ES (Encrypted State)

SEV-ES(Encrypted State)는 SEV에 게스트 레지스터 상태(VMCB Save Area) 암호화를 추가합니다. 기존 SEV에서는 VMEXIT 시 하이퍼바이저가 게스트의 RAX, RBX 등 범용 레지스터를 VMCB에서 읽을 수 있어, 민감한 데이터가 레지스터를 통해 노출될 위험이 있었습니다. SEV-ES는 VMCB Save Area를 VM의 암호화 키로 암호화하여 이 문제를 해결합니다. 대신 게스트와 하이퍼바이저 사이의 통신에 #VC(VMM Communication Exception) 핸들러(Handler)와 GHCB(Guest-Hypervisor Communication Block) 프로토콜이 필요합니다.

#VC 예외 처리 흐름

SEV-ES 게스트에서 CPUID, I/O 포트 접근, MSR 읽기/쓰기 등 하이퍼바이저 개입이 필요한 명령은 #VC(VMM Communication Exception, 벡터 29) 예외를 발생시킵니다. #VC는 기존 #GP나 #PF와 유사하게 IDT를 통해 전달됩니다. 게스트 커널의 #VC 핸들러가 GHCB(Guest-Hypervisor Communication Block)를 통해 요청/응답을 교환합니다.

#VC 핸들러의 역할은 "게스트가 하이퍼바이저에 최소한의 정보만 선택적으로 전달"하는 것입니다. 예를 들어, CPUID 요청 시 하이퍼바이저가 알아야 하는 정보(leaf 번호)만 GHCB에 기록하고, 게스트의 전체 레지스터 상태는 노출하지 않습니다.

/* arch/x86/coco/sev/vc.c — #VC 핸들러 핵심 */
static enum es_result vc_handle_exitcode(
    struct es_em_ctxt *ctxt,
    struct ghcb *ghcb,
    unsigned long exit_code)
{
    switch (exit_code) {
    case SVM_EXIT_CPUID:
        return vc_handle_cpuid(ghcb, ctxt);
    case SVM_EXIT_IOIO:
        return vc_handle_ioio(ghcb, ctxt);
    case SVM_EXIT_MSR:
        return vc_handle_msr(ghcb, ctxt);
    case SVM_EXIT_NPF:
        return vc_handle_mmio(ghcb, ctxt);
    default:
        return ES_UNSUPPORTED;
    }
}

/* GHCB를 통한 CPUID 에뮬레이션 */
static enum es_result vc_handle_cpuid(
    struct ghcb *ghcb,
    struct es_em_ctxt *ctxt)
{
    struct pt_regs *regs = ctxt->regs;

    ghcb_set_rax(ghcb, regs->ax);
    ghcb_set_rcx(ghcb, regs->cx);

    /* VMGEXIT로 하이퍼바이저에 요청 */
    return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_CPUID, 0, 0);
}

GHCB 프로토콜 v2

GHCB(Guest-Hypervisor Communication Block)는 2페이지(8KB) 크기의 공유 메모리 구조체(Struct)입니다. SEV-SNP에서는 GHCB 프로토콜 v2가 사용되며, NAE(Non-Automatic Exit) 이벤트 처리를 표준화합니다.

/* arch/x86/include/asm/sev-common.h — GHCB 구조체 */
struct ghcb {
    u8  reserved1[0xcb];
    u8  cpl;
    u8  reserved2[0x74];
    u64 rax;
    u8  reserved3[0x100];
    u64 rcx;
    u64 rdx;
    u64 rbx;
    u8  reserved4[0x70];
    u64 sw_exit_code;     /* NAE 이벤트 코드 */
    u64 sw_exit_info_1;   /* 이벤트 파라미터 1 */
    u64 sw_exit_info_2;   /* 이벤트 파라미터 2 */
    u64 sw_scratch;       /* 스크래치 버퍼 GPA */
    u8  reserved5[0x38];
    u64 valid_bitmap[2]; /* 유효 필드 비트맵 */
    u64 protocol_version; /* GHCB 프로토콜 버전 */
    u64 ghcb_usage;       /* GHCB 사용 유형 */
} __packed;

/* NAE 이벤트 코드 */
#define SVM_EXIT_CPUID    0x72
#define SVM_EXIT_IOIO     0x7b
#define SVM_EXIT_MSR      0x7c
#define SVM_EXIT_NPF      0x400
#define SVM_EXIT_AP_RESET_HOLD 0x80000004
#define SVM_EXIT_SNP_PSC       0x80000010 /* Page State Change */
#define SVM_EXIT_GUEST_REQUEST 0x80000011 /* 증명 요청 */

SEV-ES VMGEXIT 명령

VMGEXIT는 SEV-ES/SNP 게스트에서 사용하는 특수 VMEXIT 명령입니다. 일반 VM에서는 특정 명령(CPUID, RDMSR 등)이 자동으로 VMEXIT를 유발하지만, SEV-ES에서는 게스트가 GHCB를 설정한 후 명시적으로 VMGEXIT를 호출합니다. 이는 게스트가 어떤 정보를 하이퍼바이저에 전달할지 선택적으로 제어할 수 있음을 의미합니다.

/* VMGEXIT 실행 (어셈블리) */
/* SEV-ES/SNP에서는 "rep; vmmcall" = VMGEXIT */
static inline void sev_es_wr_ghcb_msr(u64 val)
{
    asm volatile("wrmsr"
        : : "c"(MSR_AMD64_SEV_ES_GHCB),
            "a"((u32)val),
            "d"((u32)(val >> 32)));
}

static inline void VMGEXIT(void)
{
    asm volatile("rep; vmmcall" ::: "memory");
}

SEV-ES 조기 부팅 (Early Boot)

SEV-ES 게스트의 부팅 초기 단계에서는 Linux 커널의 일반 예외 처리 인프라가 아직 초기화되지 않았습니다. 따라서 압축 해제 단계(decompressor)와 startup_64에서 별도의 #VC 핸들러가 필요합니다.

/* arch/x86/boot/compressed/sev.c — 조기 #VC 핸들러 */
void do_vc_no_ghcb(struct pt_regs *regs,
                    unsigned long exit_code)
{
    /* GHCB 초기화 전이므로 MSR 프로토콜 사용 */
    /* MSR 0xC001_0130(GHCB MSR)에 직접 요청/응답 */
    switch (exit_code) {
    case SVM_EXIT_CPUID: {
        u64 val;
        /* MSR 프로토콜: CPUID 요청 인코딩 */
        val = GHCB_CPUID_REQ_EAX |
              ((u64)regs->ax << 32);
        native_wrmsrl(MSR_AMD64_SEV_ES_GHCB, val);
        asm volatile("rep; vmmcall");
        val = native_rdmsrl(MSR_AMD64_SEV_ES_GHCB);
        regs->ax = val >> 32;
        break;
    }
    }
}

SEV-SNP

SEV-SNP(Secure Nested Paging)는 SEV-ES에 메모리 무결성 보호를 추가합니다. RMP(Reverse Map Table)가 모든 물리 페이지의 소유권을 추적하여, 하이퍼바이저의 메모리 리맵 공격(앨리어싱, 리플레이)을 차단합니다. SEV-SNP는 기밀 컴퓨팅의 "완성형"으로, 기밀성(SEV) + 레지스터 보호(ES) + 무결성(SNP) + 원격 증명을 모두 제공합니다.

VMPL (Virtual Machine Privilege Level)

SEV-SNP는 게스트 내부에 4단계 권한(VMPL 0~3)을 도입합니다. VMPL 0이 가장 높은 권한으로 SVSM이 실행되고, VMPL 2~3에서 게스트 OS가 실행됩니다.

/* arch/x86/include/asm/sev-common.h — VMPL 관련 정의 */
#define VMPL_0    0   /* 최고 권한 — SVSM 실행 */
#define VMPL_1    1   /* 예약 */
#define VMPL_2    2   /* 게스트 커널 */
#define VMPL_3    3   /* 게스트 유저스페이스 */

/* VMPL에 따른 RMP 권한 비트 */
struct rmp_entry {
    u64 gpa;
    u16 asid;
    u8  vmpl;
    u8  perms;     /* R/W/X 각 VMPL별 */
    u8  assigned : 1;
    u8  validated : 1;
    u8  immutable : 1;
};

페이지 검증 (Page Validation)

SEV-SNP 게스트는 PVALIDATE 명령으로 각 페이지를 명시적으로 검증(validate)해야 합니다. PVALIDATE는 RMP에 해당 페이지가 이 게스트의 소유임을 기록합니다. 검증되지 않은 페이지에 접근하면 #VC 예외가 발생합니다. 이 메커니즘은 하이퍼바이저가 게스트 모르게 새 페이지를 추가하는 공격을 방지합니다. 게스트가 명시적으로 검증하지 않은 페이지는 접근할 수 없으므로, 악의적 페이지 주입이 차단됩니다.

/* arch/x86/kernel/sev.c — PVALIDATE 래퍼 */
static int pvalidate_pages(unsigned long vaddr,
                          unsigned int npages, bool validate)
{
    unsigned long va = vaddr;
    int i, rc;

    for (i = 0; i < npages; i++, va += PAGE_SIZE) {
        /* PVALIDATE: RMP에 이 페이지가 이 게스트 소유임을 기록 */
        rc = pvalidate(va, RMP_PG_SIZE_4K, validate);
        if (rc)
            return rc;
    }
    return 0;
}

SEV-SNP 증명

원격 증명(Remote Attestation)은 "이 VM이 기대한 코드와 설정으로 기밀 환경에서 실행 중임"을 제3자가 검증하는 프로토콜입니다. 기밀 컴퓨팅에서 증명은 신뢰의 기반입니다. 메모리 암호화만으로는 "이 VM이 정말 기밀 환경에서 실행 중인지" 확인할 수 없으므로, 하드웨어가 서명한 보고서를 통해 검증합니다. SEV-SNP는 PSP가 서명한 Attestation Report를 제공합니다.

증명 요청 코드

/* 사용자 공간에서 증명 보고서 요청 (snp-attestation-report) */
#include <linux/sev-guest.h>
#include <sys/ioctl.h>

int get_attestation_report(void) {
    int fd = open("/dev/sev-guest", O_RDWR);
    struct snp_guest_request_ioctl req = {};
    struct snp_report_req report_req = {};
    struct snp_report_resp report_resp = {};

    /* 64바이트 사용자 데이터 (nonce, challenge) */
    memcpy(report_req.user_data, nonce, 64);
    report_req.vmpl = 0;

    req.msg_version = 1;
    req.req_data = (__u64)&report_req;
    req.resp_data = (__u64)&report_resp;

    return ioctl(fd, SNP_GET_REPORT, &req);
}

SNP 증명 보고서 검증 예시

# snpguest CLI를 사용한 증명 보고서 획득 및 검증

# 1. 증명 보고서 요청 (게스트 내부)
snpguest report attestation.bin request.bin --random
# attestation.bin: 1184바이트 바이너리 보고서

# 2. 보고서 내용 확인
snpguest display report attestation.bin
# Version:       2
# Guest SVN:     1
# Policy:        0x30000 (SMT 허용, 디버그 금지)
# Measurement:   a1b2c3d4...  (SHA-384)
# Platform Info: SME | SEV | SEV-ES | SEV-SNP
# Signing Key:   VCEK

# 3. VCEK 인증서 다운로드 (AMD KDS)
snpguest fetch vcek der \
  --processor-model Milan \
  /tmp/certs/

# 4. 인증서 체인 확인
snpguest verify certs /tmp/certs/
# ARK → ASK → VCEK: OK

# 5. 보고서 서명 검증
snpguest verify attestation attestation.bin /tmp/certs/
# Attestation report signature verification: SUCCESS

증명 정책 필드 상세

SNP 게스트 초기화 흐름

SEV-SNP 게스트의 Linux 커널 초기화는 일반 VM과 다른 특수 경로를 거칩니다.

/* arch/x86/coco/sev/core.c — SNP 게스트 초기화 순서 */

/* 1. 조기 탐지 (startup_64 이전) */
/*    CPUID Fn8000_001F — SEV/ES/SNP 비트 확인 */
/*    MSR 0xC0010131 (SEV_STATUS) — 활성 기능 확인 */

/* 2. 초기화 1단계: setup_arch() */
void __init snp_init(void)
{
    /* CC 벤더 등록 */
    cc_vendor = CC_VENDOR_AMD;
    cc_set_mask(sme_me_mask);

    /* CPUID 테이블 초기화 (펌웨어가 전달한 CPUID 값 사용) */
    snp_cpuid_init();

    /* Secrets 페이지 매핑 (증명에 사용) */
    snp_map_secrets_page();
}

/* 3. 초기화 2단계: 메모리 accept */
void __init snp_accept_memory(phys_addr_t start, phys_addr_t end)
{
    unsigned long npages = (end - start) >> PAGE_SHIFT;

    /* 각 페이지를 PVALIDATE로 검증 */
    /* 또는 SVSM이 있으면 SVSM에 위임 */
    if (snp_vmpl)
        svsm_pvalidate_pages(start, npages, true);
    else
        pvalidate_pages(start, npages, true);
}

/* 4. 초기화 3단계: SWIOTLB bounce buffer 설정 */
/*    shared 영역 할당 + C-bit 클리어 */

SNP 보안 CPUID (Firmware-Validated CPUID)

SEV-SNP에서는 하이퍼바이저가 CPUID 결과를 조작할 수 있으므로, 펌웨어(OVMF)가 부팅 시 신뢰할 수 있는 CPUID 값을 CPUID 페이지에 기록합니다. 게스트 커널은 이 테이블을 참조하여 CPUID 위변조를 방지합니다.

/* arch/x86/coco/sev/core.c — 보안 CPUID 조회 */
static int snp_cpuid_calc(u32 func, u32 subfunc,
                          u32 *eax, u32 *ebx,
                          u32 *ecx, u32 *edx)
{
    const struct snp_cpuid_fn *fn;

    /* 펌웨어가 검증한 CPUID 테이블에서 조회 */
    fn = snp_cpuid_get_validated(func, subfunc);
    if (!fn)
        return -ENOENT;

    *eax = fn->eax;
    *ebx = fn->ebx;
    *ecx = fn->ecx_in == subfunc ? fn->ecx : fn->ecx_in;
    *edx = fn->edx;
    return 0;
}

Intel TDX 개요

Intel TDX(Trust Domain Extensions)는 기존 VMX(VT-x) 위에 SEAM(Secure Arbitration Mode)이라는 새로운 CPU 모드를 추가하여 Trust Domain(TD)을 생성합니다. TDX Module이라는 Intel 서명 펌웨어가 SEAM 모드에서 실행되며, TD의 메모리와 상태를 관리합니다. AMD SEV가 PSP라는 별도 하드웨어 보안 프로세서에 의존하는 반면, TDX는 메인 CPU의 새로운 동작 모드(SEAM)에서 소프트웨어(TDX Module)로 구현됩니다. 이 접근의 장점은 TDX Module을 소프트웨어 업데이트로 개선할 수 있다는 것입니다.

/* arch/x86/virt/vmx/tdx/tdx.c — TDX 모듈 초기화 */
static int __init init_tdx_module(void)
{
    int ret;

    /* 1단계: SEAMCALL[TDH.SYS.INIT] — TDX Module 초기화 */
    ret = seamcall(TDH_SYS_INIT, 0, 0, 0, 0, NULL);
    if (ret)
        return ret;

    /* 2단계: 모든 LP에서 TDH.SYS.LP.INIT 실행 */
    on_each_cpu(tdx_init_lp, NULL, 1);

    /* 3단계: TDX Module 상태를 SYS_READY로 전환 */
    ret = seamcall(TDH_SYS_CONFIG, 0, 0, 0, 0, NULL);

    pr_info("TDX module initialized successfully\n");
    return ret;
}

TDX Module 보안 속성

TDX Module은 기밀 컴퓨팅의 핵심 TCB 구성 요소입니다. 몇 가지 중요한 보안 속성을 갖고 있습니다.

/* SEAMRR — TDX Module 메모리 보호 레지스터 */
/* IA32_SEAMRR_PHYS_BASE (MSR 0x1400) — 기본 주소 */
/* IA32_SEAMRR_PHYS_MASK (MSR 0x1401) — 마스크 + 활성화 */
/*
 * SEAMRR은 SMRR(System Management Range Register)과 유사하게
 * 물리 주소 범위를 하드웨어 수준에서 보호합니다.
 * Non-SEAM 모드에서의 접근은 무조건 abort됩니다.
 * 이 영역에 TDX Module 코드, 전역 메타데이터,
 * TD Control Structure(TDCS), TD Virtual Processor State(TDVPS)
 * 등이 저장됩니다.
 */

TDX 아키텍처

TDX의 메모리 격리는 Secure EPT(SEPT)와 MKTME 암호화의 조합으로 구현됩니다. 각 TD는 고유한 HKID(Host Key ID)를 부여받으며, TDX Module만이 SEPT를 관리할 수 있습니다. VMM(KVM)은 SEAMCALL을 통해 TDX Module에 메모리 추가/제거를 요청할 수 있지만, SEPT 자체를 직접 수정할 수 없습니다. 이는 VMM이 NPT를 자유롭게 수정할 수 있는 AMD SEV(non-SNP)와의 핵심적인 차이입니다. TDX에서는 하드웨어가 아닌 TDX Module(신뢰 소프트웨어)이 페이지 테이블(Page Table) 무결성을 보장합니다.

SEAMCALL 인터페이스

/* arch/x86/virt/vmx/tdx/tdx.c — 주요 SEAMCALL 목록 */

/* TD 생명주기 관리 */
#define TDH_MNG_CREATE       0x0009  /* TD Control Structure 생성 */
#define TDH_MNG_ADDCX       0x000A  /* TD에 제어 페이지 추가 */
#define TDH_MNG_INIT        0x0011  /* TD 초기화 완료 */
#define TDH_MNG_KEY_CONFIG  0x0008  /* HKID 할당 및 키 설정 */

/* 메모리 관리 */
#define TDH_MEM_PAGE_ADD    0x0D00  /* TD에 private 페이지 추가 */
#define TDH_MEM_SEPT_ADD    0x0C00  /* SEPT 페이지 추가 */
#define TDH_MEM_PAGE_AUG    0x0D40  /* 런타임 페이지 추가 (lazy) */

/* vCPU 관리 */
#define TDH_VP_CREATE       0x000E  /* TDVPS 생성 */
#define TDH_VP_ENTER        0x0010  /* TD vCPU 진입 */

/* arch/x86/kvm/vmx/tdx.c — KVM에서 TD 생성 */
static int tdx_vm_init(struct kvm *kvm)
{
    struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
    int ret;

    /* HKID 할당 */
    ret = tdx_keyid_alloc();
    if (ret < 0)
        return ret;
    kvm_tdx->hkid = ret;

    /* TDH.MNG.CREATE — TDCS 생성 */
    ret = seamcall(TDH_MNG_CREATE, kvm_tdx->tdcs_pa,
                   kvm_tdx->hkid, 0, 0, NULL);
    return ret;
}

TD Exit 처리

TDX에서 VM Exit(TD Exit)는 SEV-ES의 #VC와 유사하게 작동합니다. 게스트가 하이퍼바이저 개입이 필요한 명령을 실행하면, TDX Module이 제한적 정보만 VMM에 전달합니다.

/* arch/x86/coco/tdx/tdx.c — TDX 게스트 VE(Virtualization Exception) 핸들러 */
bool tdx_handle_virt_exception(
    struct pt_regs *regs,
    struct ve_info *ve)
{
    unsigned long val;
    bool ret = true;

    switch (ve->exit_reason) {
    case EXIT_REASON_HLT:
        /* TDCALL[TDG.VP.VMCALL] — VMM에 HLT 알림 */
        tdx_hlt();
        break;
    case EXIT_REASON_IO_INSTRUCTION:
        /* I/O 명령 에뮬레이션 */
        ret = tdx_handle_io(regs, ve);
        break;
    case EXIT_REASON_MSR_READ:
        /* TDVMCALL로 VMM에 MSR 읽기 요청 */
        ret = tdx_handle_msr(regs, ve);
        break;
    case EXIT_REASON_CPUID:
        /* TDCALL[TDG.VP.VMCALL] — CPUID 가상화 */
        ret = tdx_handle_cpuid(regs, ve);
        break;
    case EXIT_REASON_EPT_VIOLATION:
        /* MMIO 처리 */
        ret = tdx_handle_mmio(regs, ve);
        break;
    default:
        pr_warn("TDX: unexpected VE: %ld\n",
                ve->exit_reason);
        ret = false;
    }
    return ret;
}

/* TDVMCALL — 게스트 → VMM 통신 (TDX의 VMGEXIT 대응) */
static u64 __tdx_hypercall(struct tdx_module_args *args)
{
    /* TDCALL[TDG.VP.VMCALL] leaf */
    args->r10 = TDX_HYPERCALL_STANDARD;
    return __tdcall(TDG_VP_VMCALL, args);
}

Unaccepted Memory

TDX와 SEV-SNP 모두 게스트가 사용할 메모리를 명시적으로 "수락(accept)"해야 합니다. Linux v6.5+에서는 CONFIG_UNACCEPTED_MEMORY로 lazy accept를 지원하여, 부팅 시간을 대폭 단축합니다.

/* mm/page_alloc.c — 미수락 메모리 처리 */
static void accept_page(struct page *page, unsigned int order)
{
    phys_addr_t start = page_to_phys(page);
    phys_addr_t end = start + (PAGE_SIZE << order);

    /* 아키텍처별 accept 호출 */
    /* TDX: TDCALL[TDG.MEM.PAGE.ACCEPT] */
    /* SNP: PVALIDATE */
    arch_accept_memory(start, end);
}

/* 페이지 할당자에서 on-demand accept */
struct page *__alloc_pages(gfp_t gfp, unsigned int order,
                           int nid, nodemask_t *mask)
{
    struct page *page;

    page = get_page_from_freelist(...);
    if (page && page_is_unaccepted(page))
        accept_page(page, order);  /* 최초 사용 시 accept */
    return page;
}

TDX 증명

TDX 증명은 2단계 프로토콜입니다. 1단계에서 TD 내부에서 TDCALL[TDG.MR.REPORT]로 TDREPORT를 생성합니다. TDREPORT는 로컬 검증용으로 MAC(HMAC-256)으로 보호되지만 원격 전송에는 적합하지 않습니다. 2단계에서 QE(Quoting Enclave, SGX 기반)가 TDREPORT를 ECDSA-P256으로 서명된 Quote로 변환하여 원격 검증자에게 전달합니다. TDX는 기존 SGX의 증명 인프라(DCAP, Intel PCS)를 재활용(Recycling)합니다.

/* TDX 게스트에서 TDREPORT 요청 */
#include <linux/tdx-guest.h>

int get_tdx_report(void) {
    int fd = open("/dev/tdx_guest", O_RDWR);
    struct tdx_report_req req = {};

    /* 64바이트 리포트 데이터 설정 */
    memcpy(req.reportdata, nonce, 64);

    /* TDCALL[TDG.MR.REPORT] 호출 */
    return ioctl(fd, TDX_CMD_GET_REPORT0, &req);
}

ARM CCA / Realm

ARM CCA(Confidential Compute Architecture)는 Armv9-A부터 도입된 RME(Realm Management Extension)를 기반으로 합니다. 기존 Normal/Secure 2개 세계에 Root와 Realm을 추가하여 4개 세계(World) 모델을 구현합니다. ARM의 접근은 x86과 달리 기존 TrustZone(Secure World)과 기밀 컴퓨팅(Realm World)을 완전히 분리하여, TrustZone의 TA가 기밀 VM 데이터에 접근할 수 없도록 합니다.

GPT (Granule Protection Table)

GPT는 물리 메모리(Physical Memory)의 각 granule(4KB)에 대해 소유 세계를 지정하는 2단계 계층 테이블입니다. EL3의 Monitor 펌웨어만이 GPT를 수정할 수 있으며, GPC(Granule Protection Check)가 모든 메모리 접근을 하드웨어 수준에서 검증합니다. GPT는 AMD의 RMP나 Intel의 SEPT와 유사한 역할을 하지만, ARM의 4세계 모델을 반영하여 더 세분화된 접근 제어를 제공합니다.

/* GPT 엔트리 구조 (ARM RME spec) */
/* 각 granule에 대해 2비트 PAS(Physical Address Space) 지정 */
enum gpt_pas {
    GPT_PAS_ROOT     = 0b00,  /* EL3 전용 */
    GPT_PAS_SECURE   = 0b01,  /* Secure World */
    GPT_PAS_REALM    = 0b10,  /* Realm World (기밀 VM) */
    GPT_PAS_NONSEC   = 0b11,  /* Normal World */
};

/* GPT 전환: Normal → Realm (EL3 Monitor 호출) */
/* SMC를 통해 EL3에서 실행됨 */
int gpt_transition_pas(unsigned long pa,
                       enum gpt_pas from,
                       enum gpt_pas to)
{
    /* GPT L1 엔트리 수정 */
    gpt_set_entry(pa, to);
    /* TLB 무효화 (TLBI PAALLOS) */
    tlbi_paallos();
    return 0;
}

Realm 관리

RMM(Realm Management Monitor)은 Realm World의 EL2에서 실행되며, Realm VM의 생명주기를 관리합니다. 하이퍼바이저(Normal World EL2)와 분리된 독립 소프트웨어입니다. 참조 구현체인 TF-RMM(Trusted Firmware RMM)은 ARM이 오픈소스로 제공합니다. RMM의 역할은 AMD SEV-SNP에서 PSP + RMP가 하는 역할, TDX에서 TDX Module이 하는 역할과 유사합니다.

RMI / RSI 인터페이스

Realm Translation Table (RTT)

Realm의 2단계 주소 변환(Address Translation)은 RTT(Realm Translation Table)를 통해 수행됩니다. RTT는 일반 Stage 2 페이지 테이블과 구조적으로 유사하지만, RMM만이 관리할 수 있습니다. 하이퍼바이저는 RMI를 통해 RTT 변경을 요청하고, RMM이 검증 후 적용합니다.

/* RTT 관리 RMI 명령 */
#define RMI_RTT_CREATE      0xC400_0171  /* RTT 레벨 생성 */
#define RMI_RTT_DESTROY     0xC400_0172  /* RTT 레벨 파괴 */
#define RMI_RTT_MAP         0xC400_0173  /* Non-secure IPA 매핑 */
#define RMI_RTT_UNMAP       0xC400_0174  /* IPA 매핑 해제 */
#define RMI_RTT_READ_ENTRY  0xC400_0175  /* RTT 엔트리 읽기 */
#define RMI_DATA_CREATE     0xC400_0153  /* Realm 데이터 페이지 생성 */
#define RMI_DATA_DESTROY    0xC400_0154  /* Realm 데이터 페이지 파괴 */

/* REC(Realm Execution Context) = vCPU 구조체 */
#define RMI_REC_CREATE      0xC400_015A  /* vCPU 생성 */
#define RMI_REC_DESTROY     0xC400_015B  /* vCPU 파괴 */
#define RMI_REC_ENTER       0xC400_015C  /* Realm 진입 (vCPU 실행) */

ARM CCA Linux KVM 통합

ARM CCA의 Linux KVM 지원은 v6.9+에서 실험적으로 진행 중입니다. KVM이 Normal World EL2에서 실행되며, Realm 생성 시 SMC를 통해 RMM과 통신합니다.

/* arch/arm64/kvm/rme.c — Realm VM 생성 */
int kvm_realm_create(struct kvm *kvm)
{
    struct realm *realm = &kvm->arch.realm;
    int ret;

    /* RD(Realm Descriptor) 페이지 할당 */
    realm->rd = alloc_delegated_page();

    /* SMC: RMI_REALM_CREATE */
    ret = rmi_realm_create(
        virt_to_phys(realm->rd),
        &realm->params);

    if (ret)
        return -ENXIO;

    /* RTT(Realm Translation Table) 초기화 */
    ret = realm_create_rtt_levels(kvm);

    return ret;
}

/* Realm 메모리 추가 */
int realm_map_memory(struct kvm *kvm,
                     gpa_t gpa, struct page *page)
{
    /* 1. GPT 전환: Non-secure → Realm */
    rmi_granule_delegate(page_to_phys(page));

    /* 2. Realm에 데이터 페이지 추가 */
    rmi_data_create(
        virt_to_phys(realm->rd),
        page_to_phys(page),
        gpa, RMI_MEASURE);

    return 0;
}

CCA 증명 토큰

ARM CCA의 증명은 RSI(Realm Service Interface)를 통해 Realm 내부에서 요청합니다. RMM이 CCA Platform Token을 생성하며, PSA(Platform Security Architecture) Attestation Token 형식(CBOR/COSE)을 따릅니다.

/* RSI를 통한 CCA 증명 토큰 요청 (개념 코드) */
int realm_get_attestation_token(
    void *challenge, size_t challenge_len,
    void *token_buf, size_t *token_len)
{
    struct arm_smccc_res res;

    /* RSI_ATTESTATION_TOKEN_INIT */
    arm_smccc_smc(RSI_ATTESTATION_TOKEN_INIT,
        virt_to_phys(challenge), challenge_len,
        0, 0, 0, 0, 0, &res);

    /* RSI_ATTESTATION_TOKEN_CONTINUE (반복) */
    do {
        arm_smccc_smc(RSI_ATTESTATION_TOKEN_CONTINUE,
            virt_to_phys(token_buf), PAGE_SIZE,
            0, 0, 0, 0, 0, &res);
        *token_len += res.a1;
    } while (res.a0 == RSI_INCOMPLETE);

    return (res.a0 == RSI_SUCCESS) ? 0 : -EIO;
}

SVSM (Secure VM Service Module)

SVSM(Secure VM Service Module)은 SEV-SNP의 VMPL 0에서 실행되는 보안 서비스 모듈입니다. 게스트 OS(VMPL 2)에게 vTPM, VTOM, 시크릿 주입 등의 보안 서비스를 제공합니다. TCB를 최소화하면서 TPM 기능을 기밀 VM에 제공하는 핵심 컴포넌트입니다.

coconut-svsm 프로젝트

coconut-svsm은 AMD 주도의 오픈소스 SVSM 구현체입니다(Rust 기반). ~30,000줄의 소형 TCB로, 리눅스 커널 v6.7+에서는 SVSM 인식 코드가 포함되어 있습니다. Rust의 메모리 안전성 보장으로 VMPL 0에서 실행되는 코드의 취약점을 최소화합니다.

# coconut-svsm 빌드 (Rust nightly 필요)
git clone https://github.com/coconut-svsm/svsm.git
cd svsm

# Rust 도구체인 설치
rustup toolchain install nightly
rustup target add x86_64-unknown-none

# SVSM 빌드
make FEATURES="vtpm,default-vtpm"

# 결과물: svsm.bin (VMPL 0에 로드될 바이너리)
ls -la bin/svsm.bin

# QEMU에서 SVSM과 함께 SNP VM 실행
qemu-system-x86_64 \
  -enable-kvm \
  -cpu EPYC-v4 \
  -machine q35,confidential-guest-support=sev0 \
  -object sev-snp-guest,id=sev0,cbitpos=51,\
reduced-phys-bits=1,policy=0x30000,\
svsm=bin/svsm.bin \
  ...

/* arch/x86/coco/sev/svsm.c — SVSM 호출 래퍼 */
static int svsm_perform_call_protocol(
    struct svsm_call *call)
{
    /* SVSM Calling Area에 요청 기록 */
    call->caa->call_pending = 1;
    call->caa->rax = call->rax;

    /* VMGEXIT → PSP가 VMPL 0(SVSM)으로 전환 */
    asm volatile("rep; vmmcall");

    /* SVSM 처리 완료 후 VMPL 2로 복귀 */
    return call->caa->rax;
}

/* SVSM을 통한 PVALIDATE 위임 */
int svsm_pvalidate_pages(unsigned long vaddr,
                        unsigned int npages, bool validate)
{
    struct svsm_call call = {};

    call.rax = SVSM_CORE_PVALIDATE;
    call.rcx = vaddr;
    call.rdx = npages | (validate ? SVSM_PVALIDATE_FLAG_VALIDATE : 0);

    return svsm_perform_call_protocol(&call);
}

SVSM vTPM 상세

SVSM의 가장 중요한 서비스는 vTPM 2.0입니다. 물리 TPM 없이도 기밀 VM에 TPM 기능을 제공하여, 측정 부팅(Measured Boot), BitLocker/dm-crypt 키 봉인, IMA(Integrity Measurement Architecture)를 사용할 수 있게 합니다.

/* SVSM vTPM 아키텍처 (개념 코드) */

/* VMPL 0 (SVSM) 내부 vTPM 구현 */
struct svsm_vtpm {
    u8  pcr[24][48];   /* 24개 PCR, SHA-384 */
    u8  ek_seed[32];    /* Endorsement Key 시드 */
    u8  srk[32];         /* Storage Root Key */
    bool locality_locked; /* TPM locality 잠금 */
};

/* PCR 확장 (게스트 커널 → SVSM 호출) */
int svsm_vtpm_pcr_extend(
    u32 pcr_idx,
    u16 hash_alg,
    const u8 *digest, size_t digest_len)
{
    struct svsm_call call = {
        .rax = SVSM_VTPM_CMD,
        .rcx = VTPM_CC_PCR_EXTEND,
        .rdx = pcr_idx,
    };

    /* digest를 SVSM 공유 버퍼에 복사 */
    memcpy(call.buffer, digest, digest_len);

    /* VMPL 0으로 전환하여 PCR 확장 */
    return svsm_perform_call_protocol(&call);
}

/* 시크릿 봉인 (vTPM seal) */
/* 특정 PCR 상태에서만 복호화 가능한 데이터 생성 */
/* → dm-crypt 키 보호, 설정 파일 봉인 */

SVSM 보안 서비스 전체 목록

공유/개인 메모리 모델

기밀 VM은 메모리를 private(암호화, 호스트 접근 불가)과 shared(비암호화, 호스트와 공유)로 구분합니다. I/O와 virtio 통신은 shared 메모리를 통해 이루어집니다. 이 이분법은 기밀 컴퓨팅의 근본적 설계 결정입니다: 게스트 데이터는 보호하되, 하이퍼바이저와의 통신은 허용해야 하기 때문입니다.

/* arch/x86/coco/core.c — 통합 메모리 상태 전환 API */
int set_memory_encrypted(unsigned long addr, int numpages)
{
    switch (cc_vendor) {
    case CC_VENDOR_AMD:
        /* C-bit 설정 + PVALIDATE */
        return __set_memory_enc_pgtable(addr, numpages, true);
    case CC_VENDOR_INTEL:
        /* S-bit 클리어 + MapGPA(private) + PAGE.ACCEPT */
        return tdx_set_memory_private(addr, numpages);
    default:
        return 0;
    }
}

int set_memory_decrypted(unsigned long addr, int numpages)
{
    switch (cc_vendor) {
    case CC_VENDOR_AMD:
        /* C-bit 클리어 → shared로 전환 */
        return __set_memory_enc_pgtable(addr, numpages, false);
    case CC_VENDOR_INTEL:
        /* S-bit 설정 + MapGPA(shared) */
        return tdx_set_memory_shared(addr, numpages);
    default:
        return 0;
    }
}

SEV-SNP Page State Change (PSC)

SEV-SNP에서 private↔shared 전환은 PSC(Page State Change) 프로토콜을 통해 수행됩니다. 게스트가 GHCB를 통해 VMM에 상태 변경을 요청하고, VMM이 RMP 업데이트를 처리합니다.

/* arch/x86/coco/sev/core.c — PSC 요청 */
static int snp_set_page_state(
    unsigned long paddr,
    unsigned int npages,
    int op)  /* SNP_PAGE_STATE_PRIVATE or SHARED */
{
    struct ghcb *ghcb;
    struct psc_entry *entries;
    int i, ret;

    ghcb = __sev_get_ghcb(&state);

    /* PSC 엔트리 배열 구성 */
    for (i = 0; i < npages; i++) {
        entries[i].gfn = (paddr >> PAGE_SHIFT) + i;
        entries[i].operation = op;
        entries[i].pagesize = RMP_PG_SIZE_4K;
    }

    /* GHCB NAE: SVM_EXIT_SNP_PSC */
    ghcb_set_sw_exit_code(ghcb, SVM_VMGEXIT_PSC);
    ghcb_set_sw_exit_info_2(ghcb, __pa(entries));

    /* VMGEXIT → VMM이 RMP 업데이트 */
    sev_es_wr_ghcb_msr(__pa(ghcb));
    VMGEXIT();

    /* 결과 확인 */
    ret = ghcb->save.sw_exit_info_2;
    __sev_put_ghcb(&state);
    return ret;
}

/* 호스트 KVM 측 PSC 처리 */
/* arch/x86/kvm/svm/sev.c */
static int snp_handle_page_state_change(
    struct kvm_vcpu *vcpu)
{
    struct psc_entry *entry;

    for (i = 0; i < count; i++) {
        entry = &entries[i];
        if (entry->operation == SNP_PAGE_STATE_PRIVATE) {
            /* RMPUPDATE: Shared → Private */
            rmpupdate(entry->gfn << PAGE_SHIFT,
                      vcpu->kvm->arch.sev_info.asid,
                      RMP_ASSIGNED);
        } else {
            /* RMPUPDATE: Private → Shared */
            rmpupdate(entry->gfn << PAGE_SHIFT,
                      0, 0);
        }
    }
    return 0;
}

TDX MapGPA 프로토콜

TDX에서는 TDCALL[TDG.VP.VMCALL]의 MapGPA 서브콜을 통해 shared↔private 전환을 수행합니다.

/* arch/x86/coco/tdx/tdx.c — MapGPA로 메모리 상태 전환 */
static int tdx_map_gpa(phys_addr_t start,
                       phys_addr_t end, bool map_private)
{
    struct tdx_module_args args = {};
    u64 ret;

    /* shared GPA = GPA | shared_bit */
    /* private GPA = GPA (shared_bit 미설정) */
    args.r11 = TDVMCALL_MAP_GPA;
    args.r12 = map_private ? start : (start | tdx_shared_mask());
    args.r13 = end - start;

    ret = __tdx_hypercall(&args);
    if (ret)
        pr_err("TDX: MapGPA failed: %lld\n", ret);

    /* private으로 전환 시 PAGE.ACCEPT 필요 */
    if (map_private)
        tdx_accept_pages(start, end);

    return ret ? -EIO : 0;
}

게스트 펌웨어

기밀 VM의 초기 부팅 코드는 TCB에 포함되므로, 전용 펌웨어가 필요합니다. 일반 OVMF를 사용하면 #VC 핸들러, 메모리 검증, 증명 초기화 코드가 없어 부팅에 실패합니다. OVMF(Open Virtual Machine Firmware)의 기밀 컴퓨팅 전용 빌드가 표준이며, 대안으로 TCB를 더 줄인 TD-Shim(TDX)이나 Direct Boot(커널 직접 부팅)도 사용됩니다.

# SEV용 OVMF 빌드
git clone https://github.com/tianocore/edk2.git
cd edk2 && git submodule update --init
source edksetup.sh
build -a X64 -t GCC5 -p OvmfPkg/AmdSev/AmdSevX64.dsc -b RELEASE

# TDX용 OVMF 빌드
build -a X64 -t GCC5 -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -b RELEASE

KVM 통합

리눅스 KVM은 기밀 컴퓨팅 VM을 관리하기 위해 fd-based private memory(gmem, guest_memfd) 아키텍처를 도입했습니다. 이 설계는 기밀 컴퓨팅의 가장 근본적인 요구사항을 해결합니다: "호스트가 게스트 메모리에 접근할 수 없어야 한다." 전통적 KVM에서는 호스트가 게스트 메모리를 mmap()으로 매핑하여 QEMU 프로세스(Process)가 직접 읽고 쓸 수 있었지만, 기밀 VM에서는 이것이 보안 위반입니다. guest_memfd는 물리 페이지를 할당하되 호스트 주소 공간(Address Space)에 매핑하지 않는 새로운 메모리 관리 방식입니다.

KVM API 확장

/* include/uapi/linux/kvm.h — 기밀 VM 관련 API */

/* 기밀 VM 유형 */
#define KVM_X86_SEV_VM         2
#define KVM_X86_SEV_ES_VM      3
#define KVM_X86_SNP_VM         4
#define KVM_X86_TDX_VM         5

/* guest_memfd 생성 */
struct kvm_create_guest_memfd {
    __u64 size;       /* private 메모리 크기 */
    __u64 flags;      /* 예약 */
    __u64 reserved[6];
};

/* 사용 예: SEV-SNP VM 생성 */
int create_snp_vm(void)
{
    int kvm_fd = open("/dev/kvm", O_RDWR);
    int vm_fd;
    struct kvm_create_guest_memfd gmem = {
        .size = 256 * 1024 * 1024,  /* 256 MB */
    };

    /* SNP VM 생성 */
    vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, KVM_X86_SNP_VM);

    /* private 메모리 할당 */
    int gmem_fd = ioctl(vm_fd, KVM_CREATE_GUEST_MEMFD, &gmem);

    /* memory slot에 guest_memfd 연결 */
    struct kvm_userspace_memory_region2 region = {
        .slot = 0,
        .guest_phys_addr = 0,
        .memory_size = gmem.size,
        .guest_memfd = gmem_fd,
        .guest_memfd_offset = 0,
    };
    ioctl(vm_fd, KVM_SET_USER_MEMORY_REGION2, &region);

    return vm_fd;
}

KVM 호스트 측 SEV-SNP 흐름

/* arch/x86/kvm/svm/sev.c — SNP VM 생성 상세 */
int sev_vm_init(struct kvm *kvm)
{
    struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
    int ret;

    /* ASID 할당 */
    ret = sev_asid_new(sev);
    if (ret)
        return ret;

    /* PSP에 LAUNCH_START 명령 전송 */
    struct sev_data_launch_start start = {
        .handle = 0,
        .policy = sev->policy,
    };
    ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_START,
                        &start, &sev->error);

    /* 초기 메모리 로드: LAUNCH_UPDATE_DATA */
    /* 각 페이지가 측정값(MEASUREMENT)에 포함됨 */

    /* SNP의 경우: SNP_LAUNCH_START → SNP_LAUNCH_UPDATE → */
    /* SNP_LAUNCH_FINISH (측정값 봉인) */
    return ret;
}

/* vCPU 실행 루프 — SEV-SNP 특화 처리 */
static int sev_handle_vmgexit(struct kvm_vcpu *vcpu)
{
    struct ghcb *ghcb = svm_get_ghcb(vcpu);
    u64 exit_code = ghcb->save.sw_exit_code;

    switch (exit_code) {
    case SVM_VMGEXIT_PSC:
        return snp_handle_page_state_change(vcpu);
    case SVM_VMGEXIT_GUEST_REQUEST:
        return snp_handle_guest_request(vcpu);
    case SVM_VMGEXIT_EXT_GUEST_REQUEST:
        return snp_handle_ext_guest_request(vcpu);
    case SVM_VMGEXIT_AP_CREATION:
        return snp_handle_ap_creation(vcpu);
    default:
        pr_warn_ratelimited(
            "SNP: unhandled VMGEXIT: 0x%llx\n",
            exit_code);
        return -EINVAL;
    }
}

guest_memfd 내부 구현

/* virt/kvm/guest_memfd.c — fd-based private memory */
static long kvm_gmem_allocate(
    struct inode *inode,
    loff_t offset, loff_t len)
{
    struct folio *folio;
    pgoff_t index;

    for (index = offset >> PAGE_SHIFT;
         index < (offset + len) >> PAGE_SHIFT; index++) {
        /* shmem에서 folio 할당 */
        folio = shmem_get_folio(inode, index);

        /* 핵심: 호스트 프로세스의 page table에 매핑하지 않음 */
        /* folio는 KVM 내부에서만 참조, QEMU는 접근 불가 */

        /* folio를 하드웨어에 등록 */
        /* SEV-SNP: RMP에 guest-owned로 설정 */
        /* TDX: SEPT에 매핑, HKID 키로 암호화 */
        kvm_gmem_prepare(kvm, folio);
    }
    return 0;
}

/* guest_memfd의 핵심 보안 속성 */
/* 1. mmap 불가: 호스트 유저스페이스에서 접근 차단 */
/* 2. read/write 불가: 호스트 커널에서도 내용 접근 차단 */
/* 3. fork 시 공유 안 됨: CoW 방지 */
/* 4. swap out 불가: 평문이 디스크에 기록되는 것 방지 */

virtio & Bounce Buffer

기밀 VM에서 virtio I/O는 shared 메모리를 통해 수행되어야 합니다. private 메모리의 DMA 요청은 SWIOTLB bounce buffer를 거쳐 shared 영역으로 복사됩니다. 이 과정은 게스트 커널의 DMA 계층에서 자동으로 처리되며, 장치 드라이버(Device Driver)는 기밀 VM 여부를 인식하지 않아도 됩니다(투명 처리). 그러나 bounce 복사는 성능 비용이 있으므로, I/O 집약적 워크로드에서는 이것이 주요 병목(Bottleneck)이 됩니다.

/* kernel/dma/swiotlb.c — 기밀 VM을 위한 bounce buffer */
phys_addr_t swiotlb_tbl_map_single(
    struct device *dev,
    phys_addr_t orig_addr,
    size_t mapping_size,
    enum dma_data_direction dir)
{
    unsigned long flags;
    phys_addr_t tlb_addr;
    int index;

    /* shared(비암호화) bounce buffer에서 슬롯 할당 */
    index = swiotlb_find_slots(dev, orig_addr, mapping_size);

    tlb_addr = slot_addr(mem->start, index);

    /* DMA_TO_DEVICE: private → shared 복사 */
    if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
        swiotlb_bounce(dev, tlb_addr, mapping_size,
                       DMA_TO_DEVICE);

    return tlb_addr;
}

SWIOTLB 내부 구조

기밀 VM의 SWIOTLB는 부팅 초기에 shared(비암호화) 메모리 영역을 확보하고, 모든 DMA 연산을 이 영역을 통해 중계합니다.

/* kernel/dma/swiotlb.c — CoCo 전용 SWIOTLB 초기화 */
void __init swiotlb_init_remap(bool addressing_limited,
                               unsigned int flags,
                               int (*remap)(void *, unsigned long))
{
    size_t alloc_size;
    void *vaddr;

    /* 기밀 VM에서는 기본 크기를 키움 */
    if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
        swiotlb_adjust_nareas(num_possible_cpus());

    alloc_size = default_nslabs << IO_TLB_SHIFT;

    /* bounce buffer 메모리 할당 */
    vaddr = memblock_alloc(alloc_size, PAGE_SIZE);

    /* 이 영역을 shared(비암호화)로 전환 */
    /* SEV: C-bit 클리어, TDX: S-bit 설정 */
    set_memory_decrypted((unsigned long)vaddr,
                         alloc_size >> PAGE_SHIFT);
}

/* DMA 경로: private 데이터 → bounce → 장치 */
/*
 * [Guest Private Memory] ──memcpy──→ [Shared Bounce Buffer]
 *     (암호화됨)                          (비암호화)
 *                                           │
 *                                    DMA to device
 *                                           │
 *                                    [I/O 장치]
 */

virtio 성능 최적화

성능 오버헤드

기밀 컴퓨팅의 주요 성능 비용은 메모리 암호화, bounce buffer I/O, 페이지 상태 전환에서 발생합니다. 성능 오버헤드의 대부분은 I/O 경로에서 발생하며, 순수 CPU/메모리 연산에서는 오버헤드가 미미합니다. 이는 AES-XTS 엔진이 메모리 컨트롤러에 통합되어 거의 라인 레이트로 동작하기 때문입니다.

벤치마크 비교

# 기밀 VM 성능 측정 (sysbench 메모리)
# 비기밀 VM
sysbench memory --memory-block-size=4K --threads=8 run
# 결과: 8192.34 MiB/sec

# SEV-SNP VM (동일 설정)
sysbench memory --memory-block-size=4K --threads=8 run
# 결과: 7946.12 MiB/sec (~3% 오버헤드)

# 네트워크 I/O (iperf3)
# 비기밀: 23.8 Gbps | SEV-SNP: 19.2 Gbps (~19% 오버헤드, bounce buffer)

# 디스크 I/O (fio 4K random read, virtio-blk)
# 비기밀: 245K IOPS | SEV-SNP: 208K IOPS (~15% 오버헤드)

부팅 시간 비교

워크로드별 오버헤드 분석

# 기밀 VM 성능 프로파일링

# 1. SWIOTLB 사용량 모니터링
watch -n1 cat /sys/kernel/debug/swiotlb/io_tlb_used

# 2. #VC / VE 빈도 측정 (perf)
perf stat -e 'kvm:kvm_exit' -e 'exceptions:page_fault_kernel' \
  -p $(pgrep qemu-system) -- sleep 10

# 3. 메모리 암호화 오버헤드 (mbw 도구)
mbw -q -n 10 256
# 비기밀: 12,345 MiB/s | SNP: 12,012 MiB/s (-2.7%)

# 4. Page accept 소요 시간
dmesg | grep -i "accepted\|unaccepted"
# 출력 예: Accepted memory: 0x0 - 0x100000000 (4096 MB) in 1.2s

라이브 마이그레이션

기밀 VM의 라이브 마이그레이션은 하이퍼바이저가 메모리를 읽을 수 없으므로, 전통적 마이그레이션과 근본적으로 다릅니다. 암호화된 상태로 전송하고 목적지에서 재검증하는 프로토콜이 필요합니다. 마이그레이션은 기밀 컴퓨팅의 가장 어려운 문제 중 하나이며, 다음 도전 과제를 해결해야 합니다:

• 키 전달: 소스 VM의 암호화 키를 안전하게 목적지로 전달해야 합니다
• 측정값 연속성: 마이그레이션 후에도 동일한 증명 보고서를 생성할 수 있어야 합니다
• TOCTOU 방지: 전송 중 메모리 변조를 방지해야 합니다
• TCB 버전 호환: 소스와 목적지의 CPU/펌웨어 TCB 버전이 호환되어야 합니다
• 다운타임 최소화: 추가적인 암호 연산으로 인한 마이그레이션 시간 증가를 최소화해야 합니다

SEV-SNP 마이그레이션 프로토콜

/* SEV-SNP 마이그레이션 흐름 (개념 코드) */

/* 1단계: 소스 호스트 — Transport Key 교환 */
sev_cmd(SNP_SEND_START, &send_start);
/* PSP가 Transport Encryption Key(TEK) 파생 */

/* 2단계: 페이지 전송 (반복) */
for (page = 0; page < total_pages; page++) {
    /* PSP가 페이지를 TEK로 재암호화 → 전송 가능 형태 */
    sev_cmd(SNP_SEND_UPDATE_DATA, &send_data);
    /* 하이퍼바이저가 네트워크로 전송 (암호문만 처리) */
    migrate_page(encrypted_data);
}

/* 3단계: 목적지 호스트 — 수신 및 복원 */
sev_cmd(SNP_RECEIVE_START, &recv_start);
for (page = 0; page < total_pages; page++) {
    /* 목적지 PSP가 TEK로 복호화 → 새 VM 키로 재암호화 */
    sev_cmd(SNP_RECEIVE_UPDATE_DATA, &recv_data);
}
sev_cmd(SNP_RECEIVE_FINISH, &recv_finish);

TDX 라이브 마이그레이션

TDX의 라이브 마이그레이션은 Migration TD(Service TD)라는 특수 TD를 사용합니다. Migration TD가 소스/목적지 TDX Module 사이의 키 교환과 메모리 전송을 중재합니다.

/* TDX 라이브 마이그레이션 프로토콜 (개념 코드) */

/* 소스 호스트 */
/* 1. Migration TD 생성 및 키 교환 */
seamcall(TDH_MIG_STREAM_CREATE, src_td, mig_td);

/* 2. 페이지 내보내기 (암호화 상태 유지) */
for (gpa = 0; gpa < td_memory_size; gpa += PAGE_SIZE) {
    /* TDX Module이 페이지를 Migration Key로 재암호화 */
    seamcall(TDH_MR_FINALIZE, src_td);
    seamcall(TDH_EXPORT_PAGE, src_td, gpa, &enc_page);

    /* 암호화된 페이지를 네트워크로 전송 */
    send_encrypted_page(dest_host, enc_page);
}

/* 목적지 호스트 */
/* 3. 새 TD 생성 + 페이지 임포트 */
seamcall(TDH_MNG_CREATE, dest_td, hkid);
for (gpa = 0; gpa < td_memory_size; gpa += PAGE_SIZE) {
    seamcall(TDH_IMPORT_PAGE, dest_td, gpa, &enc_page);
    /* TDX Module이 Migration Key로 복호화 → 새 HKID 키로 재암호화 */
}

마이그레이션 시 증명 연속성

기밀 VM이 마이그레이션된 후에도 동일한 워크로드임을 증명할 수 있어야 합니다. 마이그레이션 에이전트가 소스와 목적지 양쪽의 증명 보고서를 체인으로 연결하여 연속성을 보장합니다.

기밀 컨테이너

기밀 컨테이너(Confidential Containers, CoCo)는 기밀 VM 안에서 컨테이너 워크로드를 실행합니다. CNCF(Cloud Native Computing Foundation) 산하 프로젝트로, Kata Containers의 microVM 방식을 활용하여, 각 Pod가 독립적인 기밀 VM 안에서 실행됩니다. 기존 Kubernetes 워크플로우를 최소한으로 변경하면서 기밀 컴퓨팅의 보안 이점을 활용할 수 있습니다.

CoCo 아키텍처 구성 요소

CoCo 증명 흐름 상세

기밀 컨테이너의 증명은 Pod 시작 시 자동으로 수행됩니다. attestation-agent가 하드웨어 증명 보고서를 생성하고, KBS에 전송하여 컨테이너 이미지 복호화 키를 획득합니다.

/* CoCo 증명 흐름 (의사 코드) */

/* 1. Pod 시작 시 attestation-agent 초기화 */
aa_init() {
    /* 하드웨어 증명 드라이버 탐지 */
    if (access("/dev/sev-guest"))
        tee_type = SEV_SNP;
    else if (access("/dev/tdx_guest"))
        tee_type = TDX;
}

/* 2. KBS에 증명 세션 시작 */
aa_attestation_begin() {
    /* Challenge-Response 프로토콜 */
    nonce = kbs_get_challenge();

    /* 하드웨어 증명 보고서 생성 (nonce 포함) */
    evidence = get_hw_evidence(nonce);

    /* KBS에 Evidence 전송 → 검증 → 토큰 수신 */
    token = kbs_attest(evidence);
}

/* 3. 키 릴리스 및 이미지 복호화 */
aa_get_resource() {
    /* 증명 토큰으로 컨테이너 이미지 키 요청 */
    key = kbs_get_resource(token, "image-key");

    /* 암호화된 OCI 이미지 복호화 */
    image_decrypt(encrypted_layers, key);
}

암호화 컨테이너 이미지

CoCo에서는 컨테이너 이미지 자체를 암호화하여, 호스트가 이미지 내용을 볼 수 없게 합니다. OICF(OCI Image Encryption) 스펙을 따르며, 이미지 레이어가 AES-256-GCM으로 암호화됩니다.

# 컨테이너 이미지 암호화 (skopeo + ocicrypt)
# 1. 키 생성
openssl rand -out image_key.bin 32

# 2. 이미지 암호화
skopeo copy \
  docker://myregistry/myapp:latest \
  docker://myregistry/myapp:encrypted \
  --encryption-key jwe:image_pubkey.pem

# 3. KBS에 복호화 키 등록
kbs-client --url https://kbs.example.com \
  set-resource \
  --path "default/image-key/myapp" \
  --file image_key.bin

# Kubernetes에서 기밀 Pod 배포
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: confidential-app
spec:
  runtimeClassName: kata-cc   # CoCo 런타임 클래스
  containers:
  - name: app
    image: ghcr.io/my-org/secret-app:latest
    resources:
      limits:
        memory: "512Mi"
        cpu: "1"
  - name: attestation-sidecar
    image: ghcr.io/confidential-containers/attestation-agent:latest
EOF

GPU TEE

GPU의 기밀 컴퓨팅은 CPU TEE를 GPU로 확장하여, AI/ML 워크로드의 모델과 데이터를 GPU 메모리에서도 보호합니다. LLM(Large Language Model) 추론, 의료 영상 분석, 금융 모델링 등 민감한 AI 워크로드에서 핵심적입니다. GPU 없이는 기밀 VM에서 AI 워크로드의 데이터는 보호되지만, GPU로 전송되는 순간 보호가 해제되는 "보안 갭"이 존재했습니다. GPU TEE는 이 갭을 해소합니다.

NVIDIA H100 CC 모드 설정

# NVIDIA GPU CC 모드 활성화
# 1. GPU CC 모드 확인
nvidia-smi conf-compute -grs
# GPU 0: CC Mode: OFF

# 2. CC 모드 활성화 (재부팅 필요)
nvidia-smi conf-compute -srs on -i 0
# Confidential Computing mode set to ON

# 3. 재부팅 후 확인
nvidia-smi conf-compute -grs
# GPU 0: CC Mode: ON

# 4. GPU 증명 확인
nvidia-smi conf-compute -gas
# Attestation Status: ATTESTED

# 5. GPU 증명 검증 (NVIDIA NRAS 사용)
nv-attestation-sdk verify \
  --gpu-evidence gpu_evidence.bin \
  --nras-url https://nras.attestation.nvidia.com

GPU TEE 데이터 흐름

기밀 VM에서 GPU를 사용할 때, CPU TEE와 GPU TEE 사이의 데이터는 PCIe IDE(Integrity and Data Encryption)로 보호됩니다. SPDM 프로토콜로 상호 인증 후 세션 키를 교환하고, 이후 모든 PCIe 트래픽을 AES-256-GCM으로 암호화합니다.

/* GPU TEE 데이터 흐름 (개념) */

/* 1. GPU 인증 (SPDM) */
/*    CPU TEE ←→ GPU: SPDM GET_CERTIFICATE, CHALLENGE */
/*    결과: 상호 인증 + 세션 키 교환 */

/* 2. PCIe IDE 키 프로그래밍 */
/*    IDE 스트림 키를 PCIe 컨트롤러에 설정 */
/*    모든 TLP(Transaction Layer Packet) 암호화 */

/* 3. 데이터 전송 (암호화된 PCIe) */
/*    CPU 메모리(private) → PCIe(IDE 암호화) → GPU VRAM(암호화) */
/*    GPU VRAM(암호화) → PCIe(IDE 암호화) → CPU 메모리(private) */

/* 4. GPU 컴퓨트 */
/*    GPU 내부에서 복호화 → 연산 → 재암호화 */
/*    외부에서 VRAM 내용 접근 불가 */

SEV-TIO (Trusted I/O) 개요

AMD SEV-TIO는 SEV-SNP를 PCIe 장치로 확장하여, GPU 등의 가속기 메모리를 RMP로 보호합니다. PCIe 6.0의 TDISP 프로토콜을 구현하며, 장치 메모리를 게스트 VM의 private 영역으로 편입시킵니다.

CSP별 구현

주요 CSP(Cloud Service Provider)별 기밀 컴퓨팅 서비스 현황입니다.

CSP 기밀 컴퓨팅 비교 상세

Azure SEV-SNP 예시

GCP Confidential VM 예시

# GCP에서 SEV-SNP 기밀 VM 생성
gcloud compute instances create my-cc-vm \
  --zone=us-central1-a \
  --machine-type=n2d-standard-4 \
  --min-cpu-platform="AMD Milan" \
  --confidential-compute-type=SEV_SNP \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=confidential-vm-images \
  --maintenance-policy=TERMINATE

# 기밀 VM 상태 확인
gcloud compute instances describe my-cc-vm \
  --format="value(confidentialInstanceConfig)"
# enableConfidentialCompute: true
# confidentialInstanceType: SEV_SNP

# GKE에서 기밀 노드풀 생성
gcloud container node-pools create cc-pool \
  --cluster=my-cluster \
  --machine-type=n2d-standard-4 \
  --enable-confidential-nodes \
  --num-nodes=3

Azure SEV-SNP 예시

# Azure CLI로 SEV-SNP 기밀 VM 생성
az vm create \
  --resource-group myRG \
  --name myConfVM \
  --image Canonical:0001-com-ubuntu-confidential-vm-jammy:22_04-lts-cvm:latest \
  --size Standard_DC4as_v5 \
  --security-type ConfidentialVM \
  --os-disk-security-encryption-type VMGuestStateOnly \
  --enable-secure-boot true \
  --enable-vtpm true

# 증명 토큰 확인 (게스트 내부)
curl -H Metadata:true \
  "http://169.254.169.254/metadata/THIM/amd/certification" \
  | python3 -m json.tool

증명 서비스

원격 증명 서비스는 기밀 VM의 증명 보고서를 검증하고, 검증 성공 시 키/시크릿을 릴리스하는 인프라입니다. 증명 서비스는 Reference Values(기대 측정값)와 실제 Evidence(증명 보고서)를 비교하여 "이 VM이 기대한 소프트웨어 스택으로 실행 중인지" 판정합니다.

Intel Trust Authority 사용 예시

# Intel Trust Authority CLI (trustauthority-cli)

# 1. TDX 게스트에서 Quote 생성
trustauthority-cli quote --tee tdx --user-data $(echo -n "nonce123" | base64)
# Output: base64 encoded TDX Quote

# 2. Intel Trust Authority에 Quote 전송 및 검증
trustauthority-cli verify-quote \
  --api-url https://api.trustauthority.intel.com \
  --api-key $ITA_API_KEY \
  --quote quote.bin

# 3. 검증 결과 (JWT 토큰)
# {
#   "attester_type": "TDX",
#   "tdx_mrtd": "a1b2c3...",
#   "tdx_rtmr0": "d4e5f6...",
#   "tdx_seamsvn": 3,
#   "evaluation_status": "healthy",
#   "exp": 1720000000
# }

# 4. JWT를 사용하여 KMS에서 키 획득
curl -H "Authorization: Bearer $JWT_TOKEN" \
  https://kms.example.com/v1/keys/my-encryption-key

CoCo 통합 증명 프레임워크

CNCF Confidential Containers 프로젝트는 CoCo AS(Attestation Service)와 KBS(Key Broker Service)를 통합한 증명 프레임워크를 제공합니다. 이 프레임워크는 SEV-SNP, TDX, CCA 등 다양한 TEE를 통합 지원합니다.

# CoCo KBS 배포 (Kubernetes)
kubectl apply -f https://github.com/confidential-containers/\
trustee/releases/latest/deploy/kbs.yaml

# 리소스 등록 (컨테이너 이미지 키)
kbs-client config \
  --auth-private-key admin.key set-resource \
  --path "default/images/myapp-key" \
  --resource-file image_key.bin

# 증명 정책 업로드
kbs-client config \
  --auth-private-key admin.key set-attestation-policy \
  --policy-file reference_values.rego

RATS (Remote ATtestation procedureS) 아키텍처

IETF RATS(RFC 9334)는 원격 증명의 표준 아키텍처를 정의합니다.

/* RATS 아키텍처의 3개 역할 */

/* 1. Attester — 증명 증거 생성 (기밀 VM) */
/*    Evidence = HW Attestation Report + 추가 클레임 */

/* 2. Verifier — 증거 검증 (MAA, ITA, KBS) */
/*    Input: Evidence + Reference Values + Endorsements */
/*    Output: Attestation Result (pass/fail + 토큰) */

/* 3. Relying Party — 결과에 따라 접근 결정 */
/*    검증 성공 시: 키 릴리스, 데이터 접근 허용 */
/*    검증 실패 시: 접근 거부 */

/* 증명 흐름 모델 */
/* Background Check: Attester → Relying Party → Verifier */
/* Passport:          Attester → Verifier → Token → RP    */

KBS 정책 예시 (OPA/Rego)

# KBS 증명 정책 (Rego 언어)
# reference_values.rego
package policy

import future.keywords.if

default allow := false

# SEV-SNP 증명 정책
allow if {
    input.tee == "sevsnp"
    # 측정값(MEASUREMENT) 검증
    input.tcb.measurement == "expected_measurement_sha384_hex"
    # 최소 TCB 버전 요구
    input.tcb.snp_version >= 14
    input.tcb.microcode >= 209
    # 디버그 모드 비허용
    input.policy.debug == false
    # SMT 정책
    input.policy.smt_allowed == true
}

# TDX 증명 정책
allow if {
    input.tee == "tdx"
    input.tcb.mrtd == "expected_mrtd_sha384_hex"
    input.tcb.tdx_module_version >= "1.5.0"
    input.attributes.debug == false
}

증명 흐름 통합: Passport vs Background Check

커널 설정 종합

기밀 컴퓨팅을 위한 커널 설정은 호스트(KVM 하이퍼바이저)와 게스트(기밀 VM) 양쪽에서 필요합니다. 잘못된 설정은 기밀 VM이 생성되지 않거나, 부팅 실패, 성능 저하의 원인이 됩니다.

호스트 (KVM) 설정

# SEV/SEV-ES/SEV-SNP 호스트 지원
CONFIG_KVM_AMD_SEV=y
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=y
CONFIG_CRYPTO_DEV_SP_PSP=y

# TDX 호스트 지원
CONFIG_INTEL_TDX_HOST=y
CONFIG_KVM_INTEL_TDX=y

# guest_memfd (fd-based private memory)
CONFIG_KVM_GENERIC_PRIVATE_MEM=y

# IOMMU (기밀 I/O 보호)
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
CONFIG_INTEL_IOMMU=y

게스트 설정

# 공통 CoCo 게스트 지원
CONFIG_CONFIDENTIAL_COMPUTING=y

# AMD SEV 게스트
CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y
CONFIG_SEV_GUEST=y          # /dev/sev-guest 장치

# Intel TDX 게스트
CONFIG_INTEL_TDX_GUEST=y
CONFIG_TDX_GUEST_DRIVER=y   # /dev/tdx_guest 장치

# 공통 인프라
CONFIG_SWIOTLB=y            # bounce buffer (필수)
CONFIG_UNACCEPTED_MEMORY=y  # lazy accept 지원
CONFIG_EFI=y                # OVMF 연동

# 디버깅
CONFIG_DYNAMIC_DEBUG=y
CONFIG_CRYPTO_DEV_CCP_DEBUGFS=y

ARM CCA 게스트 설정

# ARM CCA Realm 게스트 지원 (실험적)
CONFIG_ARM64_RME=y
CONFIG_KVM_ARM_RME=y

# RMM 펌웨어 빌드 (TF-RMM)
git clone https://git.trustedfirmware.org/TF-RMM/tf-rmm.git
cd tf-rmm
cmake -DRMM_CONFIG=fvp_defcfg -B build
cmake --build build

sysfs 인터페이스

# SEV/SNP sysfs 인터페이스 (호스트)
/sys/devices/virtual/misc/sev/
├── fw_version       # PSP 펌웨어 버전
├── api_major        # SEV API 메이저 버전
├── api_minor        # SEV API 마이너 버전
├── build            # PSP 빌드 번호
└── asids            # 사용 가능한 ASID 수

# TDX sysfs 인터페이스 (호스트)
/sys/firmware/tdx/
├── tdx_module_version  # TDX Module 버전
└── seamldr_version     # P-SEAMLDR 버전

# CoCo 게스트 감지 (게스트 내부)
/sys/devices/system/cpu/
├── sev              # 1 = SEV 활성
├── sev_es           # 1 = SEV-ES 활성
├── sev_snp          # 1 = SEV-SNP 활성
└── tdx              # 1 = TDX 활성

# SWIOTLB 정보
/sys/kernel/debug/swiotlb/
├── io_tlb_nslabs    # 총 슬롯 수
├── io_tlb_used      # 사용 중인 슬롯
└── io_tlb_overflow  # 오버플로우 횟수 (0이어야 정상)

커널 부트 파라미터

QEMU 실습

개발 환경에서 기밀 VM을 테스트하는 QEMU 설정입니다. 기밀 VM 실습은 반드시 지원 하드웨어(AMD EPYC 7003+, Intel SPR+)가 필요하며, 일반 데스크톱 CPU나 중첩 가상화 환경에서는 실행할 수 없습니다. BIOS/UEFI에서 해당 기능이 활성화되어 있어야 하며, 호스트 커널과 QEMU 모두 적절한 버전이어야 합니다.

SEV-SNP QEMU 실행

# 1. 호스트 확인
dmesg | grep -i "sev\|snp"
# SEV: 509 ASIDs | SEV-ES: 100 ASIDs | SEV-SNP supported
cat /sys/module/kvm_amd/parameters/sev_snp
# Y

# 2. OVMF 펌웨어 준비
ls /usr/share/edk2/ovmf/OVMF_CODE.fd  # SEV용 OVMF

# 3. SEV-SNP VM 실행
qemu-system-x86_64 \
  -enable-kvm \
  -cpu EPYC-v4 \
  -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \
  -object memory-backend-memfd,id=ram1,size=4G,share=true \
  -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,\
policy=0x30000,kernel-hashes=on \
  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
  -drive file=guest.qcow2,if=virtio \
  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
  -smp 4 -m 4G \
  -nographic

TDX QEMU 실행

# 1. TDX 호스트 확인
dmesg | grep -i tdx
# TDX module initialized successfully

# 2. TDX VM 실행
qemu-system-x86_64 \
  -enable-kvm \
  -cpu host \
  -machine q35,kernel-irqchip=split,confidential-guest-support=tdx0,\
memory-backend=ram1 \
  -object memory-backend-memfd-private,id=ram1,size=4G \
  -object tdx-guest,id=tdx0 \
  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE_TDX.fd,readonly=on \
  -drive file=guest.qcow2,if=virtio \
  -smp 4 -m 4G \
  -nographic

게스트 내 확인

# 게스트 내부에서 기밀 VM 확인
dmesg | grep -i "memory encryption\|sev\|tdx\|coco"
# Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP
# 또는: tdx: Guest detected

# CoCo 정보 확인
cat /sys/devices/system/cpu/sev
# 1

# SNP 증명 보고서 획득 (snpguest 유틸)
snpguest report attestation.bin request.bin --random
snpguest display report attestation.bin

# TDX 증명 보고서 획득
tdx_attest -r tdreport.bin

SEV-SNP QEMU 정책 플래그 상세

TDX QEMU 옵션 상세

# TDX QEMU 고급 옵션
qemu-system-x86_64 \
  -enable-kvm \
  -cpu host \
  -machine q35,kernel-irqchip=split,\
confidential-guest-support=tdx0,\
memory-backend=ram1 \
  -object memory-backend-memfd-private,id=ram1,size=8G \
  -object tdx-guest,id=tdx0,\
sept-ve-disable=on,\
debug=off \
  -drive if=pflash,format=raw,unit=0,\
file=OVMF_CODE_TDX.fd,readonly=on \
  -drive if=virtio,format=qcow2,\
file=tdx-guest.qcow2 \
  -device virtio-net-pci,netdev=net0 \
  -netdev user,id=net0 \
  -smp 8 -m 8G \
  -nographic

# sept-ve-disable: EPT violation을 #VE 대신 TD Exit으로 처리
# debug: 디버그 TD 활성화 (프로덕션에서 반드시 off)

SEV vs TDX vs CCA 상세 비교

아키텍처 설계 철학 비교

Linux 커널 소스 트리 위치

향후 전망

기밀 컴퓨팅은 빠르게 진화하고 있습니다. 주요 발전 방향은 다음과 같습니다.

SEV-SNP vs TDX 인터럽트 처리 비교

CC 관련 Linux 커밋 히스토리

보안 권고 및 CVE

트러블슈팅

일반적인 오류 메시지 해석

# SEV-SNP 관련 커널 로그 메시지 해석

# "SEV: GHCB protocol version mismatch"
# 원인: 게스트/호스트 GHCB 프로토콜 버전 불일치
# 해결: 양쪽 커널을 동일 GHCB v2 지원 버전으로 업데이트

# "SEV-SNP: RMP violation at address 0x..."
# 원인: 호스트가 게스트 private 메모리에 접근 시도
# 해결: 드라이버 또는 QEMU의 잘못된 메모리 접근 확인

# "PVALIDATE failed: page already validated"
# 원인: 이미 검증된 페이지를 중복 검증
# 해결: PVALIDATE 전 RMP 상태 확인 로직 추가

# "TDX: SEAMCALL failed: TDX_OPERAND_BUSY"
# 원인: 다른 LP가 동일 TDX 자원을 사용 중
# 해결: 재시도 로직 추가 (경합 상태)

# "TDX: not enough free KeyIDs"
# 원인: HKID 풀 소진 (동시 TD 수 초과)
# 해결: 미사용 TD 정리 또는 BIOS에서 KeyID 수 조정

# "SWIOTLB: coherent allocation failed"
# 원인: bounce buffer 공간 부족
# 해결: swiotlb 커널 파라미터 증가

디버깅 도구

# SEV-SNP 디버깅
# PSP 펌웨어 버전
cat /sys/devices/virtual/misc/sev/fw_version

# SEV 관련 커널 로그
dmesg | grep -iE "sev|snp|ccp|psp"

# GHCB 관련 로그
dmesg | grep -i ghcb

# RMP 테이블 정보 (호스트)
cat /sys/kernel/mm/sev/rmp_base
cat /sys/kernel/mm/sev/rmp_end

# sevctl — SNP 플랫폼 정보
sevctl ok        # 플랫폼 상태 확인
sevctl show      # 상세 정보
sevctl export    # 인증서 체인 내보내기

# TDX 디버깅
dmesg | grep -i tdx
cat /sys/firmware/tdx/tdx_module_version

# CoCo 게스트 타입 확인 (범용)
cat /sys/devices/system/cpu/sev      # 1 = SEV 활성
cat /sys/devices/system/cpu/tdx      # 1 = TDX 활성

# SWIOTLB 상태
cat /sys/kernel/debug/swiotlb/io_tlb_used
cat /sys/kernel/debug/swiotlb/io_tlb_nslabs

종합 디버깅 체크리스트

관련 문서

기밀 컴퓨팅은 가상화, 보안, 메모리 관리, 암호화 등 다양한 커널 서브시스템과 연결됩니다. 아래 문서를 함께 읽으면 전체적인 이해가 깊어집니다.

• 가상화 개요 — KVM, VMX/SVM, 가상 메모리(Virtual Memory), vCPU 관리
• 커널 보안 개요 — LSM 프레임워크, Capabilities, 보안 모델
• 커널 하드닝 — KASLR, KPTI, CFI, Spectre/Meltdown 방어
• Secure Boot & 부팅 보안 — UEFI Secure Boot, 신뢰 체인(Chain of Trust), MOK
• TrustZone / OP-TEE — ARM TrustZone, Secure World, TA 개발
• 커널 암호화 프레임워크 — AES, 해시, crypto API
• IOMMU — DMA 보호, 장치 격리, VFIO
• 메모리 관리 — 페이지 테이블, 가상 메모리, 물리 메모리
• 보안 취약점 사례 — Spectre, Meltdown, 하드웨어 취약점
• 하드웨어 난수 생성기 — TRNG, 엔트로피, 난수 생성
• 인라인 어셈블리(Assembly) — CPUID, MSR 접근, 원자적(Atomic) 명령어
• TPM 2.0 — vTPM 아키텍처, SVSM vTPM, dTPM/fTPM/sTPM 비교