Microsoft has announced the open source release of the OpenHCL paravirtualization layer and the OpenVMM virtual machine monitor, which is specifically designed to run OpenHCL. The OpenVMM and OpenHCL code is written in Rust and is licensed under the MIT license. OpenVMM is a second-level hypervisor that runs in the same protection ring as the operating system kernel, similar to products such as VirtualBox and VMware Workstation. It runs on top of Linux (x86_64), Windows (x86_64, Aarch64), and macOS (x86_64, Aarch64) host systems, using the KVM, SHV (Microsoft Hypervisor), WHP (Windows Hypervisor Platform), and Hypervisor.framework virtualization APIs provided by these operating systems.
Among the features supported in OpenVMM are:
- Boot in UEFI and BIOS modes, direct boot of Linux kernel;
- Support for paravirtualization based on Virtio drivers (virtio-fs, virtio-9p, virtio-net, virtio-pmem)
- Support for paravirtualization based on VMBus (storvsp, netvsp, vpci, framebuffer);
- Emulation of vTPM, NVMe, UART, i440BX + PIIX4 chipset, IDE HDD, PCI and VGA;
- Backends for passing graphics, input devices, console, storage and network access;
- Management via command line interface, interactive console, gRPC and ttrpc.
OpenHCL is positioned as an environment with paravirtualization components (paravisor) running on top of the OpenVMM hypervisor. The key feature of virtualization systems based on OpenVMM and OpenHCL is that paravirtualization components are executed not on the host system side, but in the same virtual machine with the guest system. Isolation of the paravirtualization layer from the guest operating system is provided by the second-level hypervisor OpenVMM. OpenHCL in this application can be considered as virtual firmware running at a higher privilege level than the operating system launched in the guest environment.
The separation of the guest system and OpenHCL components is carried out using the concept of virtual trust levels (VTL, Virtual Trust Level), for the implementation of which both software mechanisms and hardware technologies can be used, such as Intel TDX (Trust Domain Extensions), AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) and ARM CCA (Confidential Compute Architecture). To execute OpenHCL components, a stripped-down Linux kernel assembly is used, including only the minimum necessary components required for OpenVMM to operate.
OpenHCL can run on x86-64 and ARM64 platforms, and supports Intel TDX, AMD SEV-SNP, and ARM CCA extensions for additional isolation. OpenHCL includes a set of services, drivers, and emulators used to provide access to hardware, provide virtual devices on the guest system side, and emulate hardware devices (for example, a chip for storing cryptographic keys, vTPM, can be emulated).
To translate access to hardware on the guest system side, existing paravirtualization-enabled drivers are used, or devices can be directly bound to the virtual machine, allowing existing guest systems to be migrated to an OpenHCL-based environment without modification. OpenHCL also includes diagnostic and debugging components. virtual machines, performed using extensions to ensure confidential computing.
Unlike the existing open source project COCONUT-SVSM (Secure VM Service Module), which provides services and emulated devices for guest systems running in confidential virtual machines (CVM, Confidential Virtual Machine), OpenHCL allows the use of standard interfaces in guest systems, while COCONUT-SVSM requires the organization of special interaction with SVSM, making changes to the guest system and the use of separate drivers.
Use cases for the OpenHCL paravisor include migrating existing systems to use Azure Boost hardware accelerators without requiring changes to the guest disk image; running existing guests in virtual machines that provide confidential computing (e.g., based on Intel TDX and AMD SEV-SNP); and providing verified boot for virtual machines using UEFI Secure Boot and vTPM.
It is separately noted that the OpenVMM project is focused on use with OpenHCL and is not yet ready for stand-alone use on host systems for production deployments by end users. The following are mentioned among the OpenVMM problems that prevent its use in host environments in a traditional context, outside of the OpenHCL bundle: poor documentation of the control interface; lack of proper optimization of the backend performance for storage, network and graphics; lack of support for some drivers (for example, IDE disks and PS/2 mouse); no guarantee of API stability and functionality. At the same time, the OpenVMM and OpenHCL bundle has already reached the level of industrial implementation and is used by Microsoft in the Azure platform (Azure Boost SKU) to support the operation of more than 1.5 million virtual machines.
Source: opennet.ru
