After a year of development, the release of the free hypervisor Xen 4.17 has been published. Companies such as Amazon, Arm, Bitdefender, Citrix, EPAM Systems, and Xilinx (AMD) participated in the development of this new release. The formation of updates for the Xen 4.17 branch will continue until June 12, 2024, while the publication of vulnerability fixes will last until December 12, 2025.
Key changes in Xen 4.17:
- Partial compliance with the requirements for developing safe and reliable software in the C language, as outlined in MISRA-C specifications used for creating critical systems, has been ensured. Four directives and 24 rules of MISRA-C (out of 143 rules and 16 directives) have been officially implemented in Xen, as well as integration into the build processes of the MISRA-C static analyzer, which checks for compliance with specification requirements.
- The ability to define a static configuration of Xen for ARM systems has been provided, which rigidly specifies all resources required for booting guest systems in advance. All resources, such as shared memory, event notification channels, and the hypervisor's heap space, are pre-allocated at hypervisor startup instead of being dynamically allocated, which eliminates possible failures due to resource shortages during operation.
- Experimental (tech preview) support for I/O virtualization using VirtIO protocols has been implemented for embedded systems based on the ARM architecture. The virtio-mmio transport is used for data exchange with virtual I/O devices, enabling compatibility with a wide range of VirtIO devices. Frontend support for Linux, tools (libxl/xl), dom0less mode, and backends running in user space (tested backends include virtio-disk, virtio-net, i2c, and gpio) have been realized.
- Support for dom0less mode has been improved, allowing for operation without deploying a dom0 environment at startup. of virtual machines At an early stage of server boot. The ability to define CPU pools (CPUPOOL) during boot (through the device tree) has been provided, allowing the use of pools in configurations without dom0, for example, to bind different types of CPU cores on ARM systems based on the big.LITTLE architecture, which combines powerful but energy-consuming cores with less powerful, yet more energy-efficient cores in a single chip. Additionally, in a dom0less configuration, the ability to bind frontend/backend paravirtualization to guest systems has been provided, enabling the booting of guest systems with the necessary paravirtualized devices.
- On ARM systems, the memory virtualization structures (P2M, Physical to Machine) are now allocated from the memory pool created during domain creation, which improves isolation efficiency between guest systems in case of memory-related failures.
- For ARM systems, protection against the Spectre-BHB vulnerability has been added in the microarchitectural structures of processors.
- On ARM systems, the ability to run the Zephyr operating system in the root environment of Dom0 has been provided.
- The ability for separate (out-of-tree) hypervisor builds has been provided.
- On x86 systems, support for large IOMMU pages (superpage) is provided for all types of guest systems, which increases bandwidth when passing through PCI devices. Support for hosts equipped with up to 12 TB of RAM has been added. During boot, the ability to set cpuid parameters for dom0 is implemented. To manage hypervisor-implemented protection measures against CPU attacks in guest systems, VIRT_SSBD and MSR_SPEC_CTRL parameters have been proposed.
- The VirtIO-Grant transport is being developed separately, distinguished from VirtIO-MMIO by a higher level of security and the ability to run handlers in a separate isolated domain for drivers. In VirtIO-Grant, instead of direct memory mapping, the physical addresses of the guest system are translated into grant references, allowing the use of pre-agreed shared memory areas for data exchange between the guest system and the VirtIO backend, without granting the backend the rights to perform memory mapping. Support for VirtIO-Grant has already been implemented in the Linux kernel but is not yet included in the QEMU backends, in virtio-vhost, and in the tooling (libxl/xl).
- The development of the Hyperlaunch initiative continues, aimed at providing flexible tools for configuring the launch of virtual machines during system boot. Currently, the first set of patches is ready, allowing for the identification of PV domains and transferring their images to the hypervisor upon boot. All necessary components for launching such paravirtualized have also been implemented. domains, including Xenstore components for PV drivers. Once the patches are accepted, work will begin on enabling support for PVH and HVM devices, as well as implementing a separate domB (builder domain) suitable for organizing a measured boot, confirming the integrity of all loaded components.
- Work continues on creating a Xen port for the RISC-V architecture.
Source: opennet.ru
