Episode ini membedah lapisan virtual I/O: cara kerja ring buffer virtio dan packed virtio, virtio-iommu sebagai IOMMU paravirtualisasi, serta sandboxing Landlock dan seccomp yang mengamankan host dari VMM. Kalian juga belajar batasan device dan mengapa setiap lapisan ini krusial bagi keamanan VM.

Setelah migrasi dan snapshot di episode 10-11, sekarang kita turun ke lapisan paling fundamental: bagaimana data benar-benar mengalir antara guest dan host. Di episode 12 kita membedah virtio secara teknis — ring buffer, packed virtio, dan virtio-iommu — lalu melihat bagaimana Cloud Hypervisor melindungi dirinya sendiri dari guest yang nakal dengan sandboxing Landlock dan seccomp.
Analogi: virtio adalah jembatan lalu lintas antara guest dan device, dan IOMMU adalah satpam yang memastikan setiap kendaraan (DMA) hanya sampai ke tujuan yang sah. Tanpa satpam, guest bisa memanfaatkan bug driver untuk mengakses memory host — itulah mengapa lapisan ini tidak bisa dianggap remeh.
Device virtio berkomunikasi lewat virtqueue: satu atau lebih ring buffer yang dibagi antara guest dan host melalui memory yang sama. Ring ini berisi descriptor yang menunjuk ke buffer data:
Karena ring buffer ada di memory bersama, tidak ada biaya perpindahan konteks untuk setiap I/O — inilah rahasia efisiensi virtio. Guest menandai pekerjaan baru dengan menulis ke queue notification (dan memicu VM-exit), host menandai selesai dengan interrupt.
Versi ring klasik (split virtqueue) memakai beberapa struktur terpisah (descriptor, available ring, used ring) — itu banyak cache line yang harus dijaga sinkron. Packed virtio menggabungkan semuanya dalam satu struktur padat. Hasilnya: lebih sedikit cache misses dan pengurangan notification/interrupt, sehingga throughput meningkat pada workload I/O tinggi.
cloud-hypervisor \
--kernel kernel-vmlinux \
--disk path=os.raw \
--net tap=ch0,ip=192.168.100.1,packed=true \
--cpus boot=4 \
--memory size=4Gpacked=true pada --net mengaktifkan packed virtqueue. Di guest, konfirmasi fitur yang dinegosiasikan:
ethtool -k enp0s2 | grep -i virtio
lspci -vv -s $(lspci | grep virtio-net | awk '{print $1}') | grep -i "virtio version"Tanpa proteksi, guest driver yang buggy atau kompromi bisa mengarahkan DMA ke alamat memory fisik host — ancaman serius terhadap isolasi VM. VMM melindungi host dengan emulated IOMMU atau, untuk passthrough, hardware IOMMU. Namun ada opsi paravirtualisasi yang jauh lebih ringan: virtio-iommu.
Virtio-iommu menyediakan translasi DMA di level device: guest meminta mapping IOVA (I/O Virtual Address) ke alamat fisik, dan VMM hanya mengizinkan mapping ke memory yang sah. Ini isolasi granular per-device:
cloud-hypervisor \
--kernel kernel-vmlinux \
--disk path=os.raw \
--iommu \
--cpus boot=4 \
--memory size=4G--iommu menghubungkan perangkat virtio melalui virtio-iommu. Di guest, perangkat sekarang terlihat di balik grup IOMMU:
ls /sys/kernel/iommu_groups/Note
Virtio-iommu bukan pengganti hardware IOMMU untuk passthrough perangkat fisik. Ia menambah lapisan isolasi untuk device virtual — baik untuk melindungi host dari device yang dikompromi, maupun mempersiapkan skenario device sharing yang lebih aman.
VMM adalah proses dengan banyak privilege di host. Jika guest berhasil mengeksploitasi VMM (misal lewat bug di device model), ia bisa mengeksekusi kode di konteks host. Dua mekanisme kernel memperkecil dampaknya:
Landlock adalah LSM (Linux Security Module) yang membatasi apa yang boleh diakses proses terhadap filesystem, tanpa perlu menjalankan VMM dalam container. Cloud Hypervisor memakainya untuk menolak akses file di luar yang dibutuhkan (kernel, disk, config) — bahkan jika VMM dikompromi, eksploitasi tidak bisa membaca file lain di host.
grep landlock /proc/self/status
uname -rLandlock tersedia di kernel 5.13+. Cloud Hypervisor mengaktifkannya secara otomatis saat memungkinkan. Efek yang bisa diamati: VMM hanya bisa membuka file yang benar-benar disediakan lewat CLI (kernel, disk, config), bukan seluruh filesystem.
seccomp membatasi syscall yang boleh dipanggil proses. Cloud Hypervisor menerapkan filter seccomp sehingga hanya syscall yang dibutuhkan VMM yang diizinkan. Akibatnya, eksploitasi yang mencoba syscall berbahaya (misal ptrace, mount, reboot) akan ditolak kernel dengan SIGSYS.
cat /proc/$(pgrep -f cloud-hypervisor)/status | grep SeccompSeccomp: 2 berarti mode filter aktif (bukan 0 = nonaktif).
Selain sandbox proses, Cloud Hypervisor membatasi device apa yang bisa dibuat guest. Hanya device yang memang disediakan konfigurasi yang ada; guest tidak bisa menciptakan device baru atau mengakses resource di luar yang dipetakan. Ini prinsip least privilege diterapkan pada model device.
Warning
Sandboxing mengurangi dampak eksploitasi, bukan menghilangkannya. Kombinasi yang benar: kernel host selalu di-patch, VMM versi terbaru (perbaikan CVE), Landlock + seccomp aktif, dan image guest yang dipercaya. Tidak ada satu lapisan pun yang bisa diabaikan (kita lanjutkan di episode 13).
packed=true dengan driver guest lawas: driver lama mungkin tidak mendukung packed virtio; negosiasi turun ke mode klasik secara otomatis, tapi verifikasi fitur di guest.--iommu tanpa dukungan driver guest: guest perlu kernel dengan dukungan virtio-iommu; kernel cloud image modern sudah mendukung.Seccomp: 0 berarti filter tidak aktif — cek versi VMM dan kernel kalian.Inti yang harus dibawa pulang:
Di episode 13 selanjutnya kita akan membahas network security & isolation — isolasi TAP/bridge per-VM, firewall, isolasi vhost-user, dan studi kasus CVE-2026-27211 (exfiltration image raw virtio-blk yang diperbaiki di v50.1) lengkap dengan mitigasi dan workaround. Keamanan network adalah garis depan berikutnya.