Learn Cloud Hypervisor - Virtual I/O: Virtio, IOMMU & Security

#Introduction

After migration and snapshot in episodes 10-11, now we descend to the most fundamental layer: how data actually flows between guest and host. In episode 12 we dissect virtio technically — ring buffers, packed virtio, and virtio-iommu — then see how Cloud Hypervisor protects itself from a malicious guest with Landlock and seccomp sandboxing.

An analogy: virtio is the traffic bridge between the guest and its devices, and the IOMMU is the security guard making sure every vehicle (DMA) only reaches legitimate destinations. Without the guard, a guest could exploit a driver bug to access host memory — that's why this layer can't be taken lightly.

#How Virtio Works: Ring Buffers

#Virtqueues

Virtio devices communicate through a virtqueue: one or more ring buffers shared between guest and host through the same memory. The ring contains descriptors that point to data buffers:

• The guest produces request descriptors (e.g., "read 4096 bytes from offset X").
• The host (VMM) consumes them, executes, then produces reply descriptors.
• The guest consumes the replies and continues execution.

Because the ring buffer lives in shared memory, there's no context-switch cost per I/O — that's the secret of virtio's efficiency. The guest marks new work by writing to a queue notification (and triggering a VM-exit); the host marks completion with an interrupt.

#Packed Virtio

The classic ring version (split virtqueue) uses several separate structures (descriptors, available ring, used ring) — that's a lot of cache lines that must be kept in sync. Packed virtio combines everything into one compact structure. The result: fewer cache misses and reduced notifications/interrupts, boosting throughput on high-I/O workloads.

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --net tap=ch0,ip=192.168.100.1,packed=true \
  --cpus boot=4 \
  --memory size=4G

packed=true on --net enables the packed virtqueue. In the guest, confirm the negotiated features:

ethtool -k enp0s2 | grep -i virtio
lspci -vv -s $(lspci | grep virtio-net | awk '{print $1}') | grep -i "virtio version"

#virtio-iommu: Paravirtualized IOMMU

#The DMA Problem Without an IOMMU

Without protection, a buggy or compromised guest driver could point DMA at host physical memory addresses — a serious threat to VM isolation. The VMM protects the host with an emulated IOMMU or, for passthrough, a hardware IOMMU. But there's a much lighter paravirtualized option: virtio-iommu.

Virtio-iommu provides DMA translation at the device level: the guest requests IOVA (I/O Virtual Address) mappings to physical addresses, and the VMM only allows mappings to legitimate memory. This is granular per-device isolation:

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=os.raw \
  --iommu \
  --cpus boot=4 \
  --memory size=4G

--iommu routes virtio devices through virtio-iommu. In the guest, devices now appear behind an IOMMU group:

ls /sys/kernel/iommu_groups/

#When to Use It

• Without passthrough and with standard workloads: virtio-iommu adds protection with small overhead.
• With VFIO passthrough (episode 8): the host's hardware IOMMU remains the primary defense; virtio-iommu doesn't replace it.

#Sandboxing: Landlock and seccomp

The VMM is a highly privileged process on the host. If a guest manages to exploit the VMM (e.g., through a bug in the device model), it could execute code in host context. Two kernel mechanisms shrink the blast radius:

#Landlock

Landlock is an LSM (Linux Security Module) that restricts what a process may access in the filesystem, without needing to run the VMM inside a container. Cloud Hypervisor uses it to deny access to files beyond what it needs (kernel, disk, config) — even if the VMM is compromised, the exploit can't read other files on the host.

grep landlock /proc/self/status
uname -r

Landlock is available in kernel 5.13+. Cloud Hypervisor enables it automatically when possible. The observable effect: the VMM can only open files actually provided via the CLI (kernel, disk, config), not the whole filesystem.

#seccomp

seccomp restricts the syscalls a process may call. Cloud Hypervisor applies a seccomp filter so only the syscalls the VMM needs are allowed. As a result, an exploit that tries dangerous syscalls (e.g., ptrace, mount, reboot) is rejected by the kernel with SIGSYS.

cat /proc/$(pgrep -f cloud-hypervisor)/status | grep Seccomp

Seccomp: 2 means filter mode is active (not 0 = disabled).

#Device Limitations

Besides process sandboxing, Cloud Hypervisor restricts which devices a guest can create. Only the devices provided in the configuration exist; the guest can't create new devices or access resources outside what's mapped. This is the principle of least privilege applied to the device model.

#Common Pitfalls

• packed=true with old guest drivers: old drivers may not support packed virtio; negotiation falls back to classic mode automatically, but verify the features in the guest.
• --iommu without guest driver support: the guest needs a kernel with virtio-iommu support; modern cloud image kernels already support it.
• Landlock "too strict": if the VMM can't open a certain file, check that the CLI path is consistent — Landlock opens only the provided paths.
• Ignoring seccomp: Seccomp: 0 means the filter isn't active — check your VMM and kernel versions.

#Conclusion

Key takeaways:

• The virtqueue is a shared ring buffer at the heart of virtio's efficiency.
• Packed virtio condenses the ring structure for better cache behavior and higher throughput.
• virtio-iommu provides granular DMA isolation for virtual devices.
• Landlock limits the VMM's filesystem access; seccomp limits allowed syscalls.
• Combining sandbox + device restriction is layered defense against VMM exploits.

In the next episode, episode 13, we'll cover network security & isolation — per-VM TAP/bridge isolation, firewalls, vhost-user isolation, and the CVE-2026-27211 case study (a raw virtio-blk image exfiltration fixed in v50.1) complete with mitigations and workarounds. Network security is the next front line.