Virtualized Redox: from Virtio-FS to Cloud Hypervisor, and beyond

MJ Pooladkhay has been working on a Virtio-FS driver for Redox OS and getting Redox to run on Cloud Hypervisor. Both tasks are part of a larger project funded by NGI Zero Commons and NLnet, aiming to create a secure host for web services using Redox as a microkernel-based operating system. The guest work, funded by NGI Zero Commons and NLnet, focuses on Redox as a secure host for web services, initially as private or edge servers and eventually as multi-tenant cloud servers isolating each tenant from others.

A hypervisor is an operating system that runs other operating systems (guests) directly on the CPU. It handles system calls, context switches, and page faults, while guests are unaware of its existence. A VM exit occurs when a guest OS needs access to the hypervisor's kernel.

Redox's guest boot process is similar to that of a laptop, with virtual firmware, bootloader, and kernel code. The kernel manages memory access through page tables, converting guest virtual addresses (GVAs) to guest physical addresses (GPAs) and host virtual addresses (HVAs) to host physical addresses (HPAs). Memory access through KVM is accelerated by collapsing GPA-to-HVA conversion, reducing the performance impact of memory access.

Redox currently runs on QEMU or physical hardware, relying on legacy devices like 8259 interrupt controllers and the PIT. Modern hypervisors, such as Cloud Hypervisor, drop these legacy devices and provide a minimal set of devices, such as an I/O APIC, a serial port, a real-time clock (RTC), and VirtIO devices. This reduction in emulated devices improves security, reduces code for the guest to probe, and simplifies booting directly into the kernel (PVH direct boot).