Toward the Verification of a Simple Hypervisor

Virtualization promises significant benefits in security, efficiency, dependability, and cost. Achieving these benefits depends upon the reliability of the underlying virtual machine monitors (hypervisors). This paper describes an ongoing project to develop and verify MinVisor, a simple but functional Type-I x86 hypervisor, proving protection properties at the assembly level using ACL2. Originally based on an existing research hypervisor, MinVisor provides protection of its own memory from a malicious guest. Our long-term goal is to fully verify MinVisor, providing a vehicle to investigate the modeling and verification of hypervisors at the implementation level, and also a basis for further systems research. Functional segments of the MinVisor C code base are translated into Y86 assembly, and verified with respect to the Y86 model. The inductive assertions (also known as “compositional cutpoints”) methodology is used to prove the correctness of the code. The proof of the code that sets up the nested page tables is described. We compare this project to related efforts in systems code verification and outline some useful steps forward.

💡 Research Summary

The paper presents an ongoing research effort to build and formally verify a simple Type‑I x86 hypervisor called MinVisor, with the ultimate goal of demonstrating that high‑assurance security properties can be proved at the implementation (assembly) level. The authors argue that while virtualization offers substantial benefits in security, efficiency, dependability, and cost, these benefits are only realized if the underlying virtual machine monitor (VMM) is trustworthy. Existing commercial hypervisors are large, complex, and constantly evolving, making them unsuitable for current formal verification techniques. Consequently, the authors focus on a minimal research hypervisor that can be fully modeled and proved with the resources at hand, hoping that the techniques will later scale to larger systems.

MinVisor is a bare‑metal, 32‑bit, AMD‑V‑enabled hypervisor that runs a single guest. It is loaded via PXE by the BIOS, relocates itself to a 2 MiB‑aligned region, and then establishes protection of its own memory using AMD’s nested paging (also known as second‑level address translation). The hypervisor’s functionality is deliberately limited to essential tasks: creating a host save area and VMCB, setting up I/O and MSR permission bitmaps, configuring guest intercepts, populating nested page tables, initializing guest state, loading the guest image, activating host page tables, starting the guest, and handling nested page‑fault intercepts. The nested page tables are constructed as an identity map for the entire physical memory except for the top 2 MiB, which is marked “not present” so that any guest access to the hypervisor’s code or data triggers a hardware page fault. The intercept handler then either silently discards writes or returns a predefined string for reads, thereby protecting the hypervisor from a malicious guest.

To verify MinVisor, the authors chose to work at the machine‑code level rather than at the C source level. Since a mature formal model of the full x86 ISA is not yet available in ACL2, they extended the pedagogical Y86 model (originally developed by Bryant and O’Hallaron) into a richer “Y86++” architecture. Y86++ adds two temporary registers (IMME1, VALU1), a CR3 register for page‑table base, a carry flag, a 1‑bit guest/supervisor mode flag, and several new instructions (adcl, cmpl, sall, shrl, jb, jbe) needed to emulate the relevant x86 behavior. Memory is represented as an association list from 32‑bit addresses to 8‑bit bytes, and a nested paging mechanism modeled after Intel’s PAE is built on top of this. Paging is enabled only when the processor is in guest mode, and the page‑table hierarchy consists of a four‑entry top‑level directory (pointed to by CR3) and 512 entries per second‑level directory, each mapping a 2 MiB page. The only status bit currently modeled is the “present” flag; pages protected by MinVisor have this bit cleared, causing a page fault on access.

The verification methodology relies on ACL2’s inductive assertions, also known as compositional cutpoints. The authors decompose the assembly code into basic blocks, annotate each with pre‑ and post‑conditions, and prove that the composition of blocks preserves the intended invariants. The paper details the proof of the routine that sets up the nested page tables. The proof establishes that after execution: (1) CR3 points to a correctly initialized top‑level directory; (2) each top‑level entry points to a second‑level directory; (3) all second‑level entries map guest physical addresses to identical system physical addresses (identity mapping) except for the hypervisor’s own region, which is marked not present; and (4) the overall page‑table structure satisfies the hardware’s expectations for nested paging. The authors also discuss how the proof handles loops that iterate over the 512 entries, using loop invariants to show that each iteration correctly writes the appropriate entry and maintains the identity mapping property.

Related work is surveyed, including the seL4 microkernel verification, CertiKOS, and other efforts that verify OS kernels at the C or higher level. The authors argue that their approach differs by targeting the low‑level assembly code and by modeling hardware features (nested paging) directly, thereby providing a tighter guarantee that the verified code will behave as intended on real hardware. They also note that the Y86++ model is deliberately close to x86, so that once a full x86 model becomes available in ACL2, the existing proofs can be ported with minimal changes.

The paper concludes with a roadmap for future work. Immediate extensions include verifying the interrupt‑handling code, adding I/O virtualization, supporting multiple guests, and improving the fidelity of the hardware model (e.g., modeling the full set of page‑table flags, handling TLB behavior, and incorporating other AMD‑V features). Longer‑term goals involve scaling the methodology to larger, more feature‑rich hypervisors and ultimately to full operating system kernels, demonstrating that high‑assurance verification can be achieved for complex system software without sacrificing practicality.