Belajar Cloud Hypervisor - Confidential Computing: TDX & SGX

#Pendahuluan

Sejauh ini kita mengasumsikan host adalah pihak yang bisa dipercaya. Tapi bagaimana jika tidak? Di cloud publik, kalian menyewa VM di server milik orang lain — siapa yang menjamin admin cloud tidak bisa membaca memory VM kalian? Ini masalah yang dijawab confidential computing: memory guest dienkripsi di level CPU sehingga host sekalipun tidak bisa membacanya.

Di episode 14 kita membahas dua teknologi Intel — TDX (Trust Domain Extensions) dan SGX (Software Guard Extensions) — yang didukung eksperimental oleh Cloud Hypervisor, plus mekanisme attestation untuk membuktikan bahwa VM berjalan di lingkungan yang benar-benar terpercaya.

#Konsep Confidential Computing

#Ancaman yang Dilawan

Dalam model keamanan tradisional, hypervisor/host dianggap trusted: ia bisa membaca memory VM karena ia yang mengalokasikannya. Confidential computing mengubah model ini: memory VM dienkripsi dengan kunci yang hanya dikenal CPU, sehingga host (termasuk kernel, driver, dan admin) hanya bisa melihat ciphertext. Jika host mencoba membaca memory VM, yang didapat hanyalah data terenkripsi yang tidak bisa didekripsi.

Ini penting untuk workload seperti model AI dengan data sensitif, kunci enkripsi, atau data medis di cloud publik.

#Dua Pendekatan Intel

TDX dan SGX mengambil jalur berbeda:

• SGX: melindungi enclave — region memory khusus di dalam sebuah proses aplikasi. Enclave diisolasi bahkan dari proses induknya dan OS.
• TDX: melindungi seluruh VM (Trust Domain). Guest VM adalah unit keamanan: seluruh memory-nya dienkripsi oleh hardware, dan VMM hanya bisa berinteraksi lewat antarmuka terbatas.

Di konteks Cloud Hypervisor, TDX lebih relevan karena sesuai dengan model "seluruh VM terlindungi". SGX lebih cocok untuk isolasi di level proses aplikasi.

#TDX di Cloud Hypervisor

#Arsitektur dan Status

Dukungan TDX di Cloud Hypervisor bersifat eksperimental. Arsitekturnya: Cloud Hypervisor berperan sebagai VMM untuk non-confidential parts (device), sementara confidential part (vCPU, memory) ditangani oleh hardware TDX. Memory Trust Domain dienkripsi otomatis; VMM hanya bisa mengakses region yang diizinkan.

Prasyarat hardware:

grep -o "tdx" /proc/cpuinfo | head -1
ls /dev/tdx_guest /dev/tdx_host 2>/dev/null

Fitur ini hanya ada di CPU Intel generasi tertentu (Sapphire Rapids dan seterusnya), dan host harus mengaktifkan TDX di BIOS serta memuat modul kernel terkait.

#Menjalankan TDX VM

Boot VM TDX pada dasarnya sama, dengan firmware dan flag khusus:

cloud-hypervisor \
  --firmware tdx-firmware.fd \
  --kernel kernel-tdx \
  --disk path=os.raw \
  --cpus boot=4 \
  --memory size=4G \
  --tdx

--tdx menandai VM sebagai Trust Domain. Di dalam guest, kernel dengan dukungan TDX akan melihat memory terenkripsi secara transparan — aplikasi tidak perlu diubah, karena enkripsi terjadi di hardware.

#SGX di Cloud Hypervisor

SGX bekerja pada level enclave aplikasi, bukan seluruh VM. Di Cloud Hypervisor, dukungan SGX memungkinkan guest menjalankan aplikasi dengan enclave yang dilindungi hardware — host tidak bisa membaca memory enclave.

grep -o "sgx" /proc/cpuinfo | head -1

Kasus pemakaian SGX yang umum: key management, HSM virtual, dan komputasi multi-party. Karena enclave berada di dalam guest, ancaman dari host masih bisa dijawab, namun enclave tetap rentan terhadap guest kernel yang berkompromi — itulah mengapa kombinasi TDX + SGX sering dianggap paling kuat.

#Attestation: Membuktikan Lingkungan

#Mengapa Attestation

Enkripsi memory saja tidak cukup — bagaimana kalian tahu bahwa memory benar-benar dienkripsi dan VM berjalan di CPU yang sah? Jawabannya attestation: proses menghasilkan quote — bukti kriptografis dari CPU bahwa lingkungan berjalan seperti yang dijanjikan.

#Alur Attestation

VM boot →  CPU menghasilkan quote (tanda tangan hardware)
    ↓
Quote dikirim ke verifier (bisa lokal atau cloud provider)
    ↓
Verifier memeriksa quote terhadap kebijakan (policy)
    ↓
Jika valid → kunci/setup dipercaya untuk memulai workload

Quote ditandatangani dengan kunci yang tertanam di CPU dan hanya valid untuk konfigurasi spesifik. Di dalam guest, mekanisme ini diekspos lewat tool atau library:

tdx-attest --quote /tmp/quote.bin

#Verifikasi Quote

Verifier memeriksa beberapa hal: identitas CPU (lewat tanda tangan quote), pengukuran (measurement) image/firmware, dan kebijakan (policy) yang diizinkan. Setelah quote diverifikasi, kalian bisa yakin memory VM tidak bisa dibaca host sebelum memberikan data sensitif.

#Batasan dan Pitfall

• Hardware langka: TDX/SGX butuh CPU Intel tertentu; di cloud publik, hanya instance yang mengekspos fitur ini (kelas "confidential").
• Eksperimental: jangan jadikan fondasi produksi sebelum fitur dianggap stabil di roadmap.
• Kernel guest: guest harus boot dengan kernel yang mendukung TDX/SGX; kernel cloud image standar belum tentu cukup.
• Attestation memakai layanan eksternal: verifier butuh akses ke layanan Intel/cloud untuk memvalidasi quote — siapkan konektivitasnya.
• Performa: enkripsi memory punya overhead; benchmark workload kalian sebelum berkomitmen.

#Penutup

Inti yang harus dibawa pulang:

• Confidential computing mengenkripsi memory VM sehingga host tidak bisa membacanya.
• TDX melindungi seluruh VM; SGX melindungi enclave di level proses.
• Dukungan TDX/SGX di Cloud Hypervisor masih eksperimental dan butuh hardware khusus.
• Attestation/quote adalah bukti kriptografis bahwa lingkungan berjalan seperti yang dijanjikan.
• "Verify before trust": beri data hanya setelah attestation sukses.
• Enkripsi punya overhead — benchmark sebelum produksi.

Di episode 15 selanjutnya kita akan menjalankan Windows guest di Cloud Hypervisor — boot Windows 10/Server lewat UEFI (CLOUDHV.fd), menginstall virtio drivers, perbedaan edk2 upstream vs fork CLOUDHV (khusus AArch64), serta best practice agar Windows berjalan stabil di atas virtio. Dari Linux melompat ke dunia Windows!