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) have contributed to the development of the new release. The formation of updates for the Xen 4.17 branch will last until June 12, 2024, and the publication of vulnerability fixes until December 12, 2025.
Key changes in Xen 4.17:
- Provided partial compliance with the requirements for the development of safe and reliable programs in the C language, formulated in the MISRA-C specifications used in the creation of critical systems. Xen officially implements 4 directives and 24 MISRA-C rules (out of 143 rules and 16 directives), as well as integration into assembly processes of the MISRA-C static analyzer, which checks compliance with the requirements of the specification.
- Provided the ability to define a static Xen configuration for ARM systems that hard-codes in advance all the resources needed to boot guest systems. All resources, such as shared memory, channels for event notification, and hypervisor heap space, are pre-allocated at hypervisor startup rather than being dynamically allocated, which eliminates potential resource bottlenecks during operation.
- For embedded systems based on the ARM architecture, experimental (tech preview) support for I/O virtualization using the VirtIO protocols has been implemented. The virtio-mmio transport is used to communicate with the virtual I / O device, which made it possible to ensure compatibility with a wide range of VirtIO devices. Implemented support for Linux frontend, toolkit (libxl/xl), dom0less mode, and userspace backends (virtio-disk, virtio-net, i2c and gpio backends tested).
- Improved support for dom0less mode, which makes it possible to avoid deploying a dom0 environment when starting virtual machines at an early stage of server boot. The ability to define CPU pools (CPUPOOL) at the boot stage (via device tree) is provided, which allows using pools in configurations without dom0, for example, to bind different types of CPU cores on ARM systems based on the big.LITTLE architecture, combining powerful, but power-consuming, cores, and less productive, but more energy efficient cores. In addition, dom0less provides the ability to bind the paravirtualization frontend / backend to guests, which allows you to boot guests with the necessary paravirtualized devices.
- On ARM systems, memory virtualization structures (P2M, Physical to Machine) are now allocated from the memory pool created when a domain is created, allowing better isolation between guests when memory-related failures occur.
- Added protection against the Specter-BHB vulnerability in processor microarchitectural structures for ARM systems.
- On ARM systems, the ability to run the Zephyr operating system in the Dom0 root environment is provided.
- The possibility of a separate (out-of-tree) hypervisor assembly is provided.
- On x86 systems, large IOMMU (superpage) pages are supported for all types of guest systems, which allows you to increase throughput when forwarding PCI devices. Added support for hosts with up to 12TB of RAM. At the boot stage, the ability to set cpuid parameters for dom0 is implemented. The VIRT_SSBD and MSR_SPEC_CTRL parameters are proposed to control the hypervisor-level protection measures against attacks on the CPU in guest systems.
- Separately, the VirtIO-Grant transport is being developed, which differs from VirtIO-MMIO in 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, translation of the guest's physical addresses into grant links is used, which allows 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. VirtIO-Grant support is already implemented in the Linux kernel, but is not yet included in the QEMU backends, virtio-vhost, and toolkit (libxl/xl).
- The Hyperlaunch initiative continues to be developed to provide flexible tools for customizing the launch of virtual machines at system boot time. At present, the first set of patches is already ready, allowing you to define PV domains and transfer their images to the hypervisor when loading. Everything needed to run such paravirtualized domains is also implemented, including Xenstore components for PV drivers. After the patches are accepted, work will begin to enable support for PVH and HVM devices, as well as the implementation of a separate domB (builder domain) suitable for organizing a measured boot (measured boot), confirming the validity of all loaded components.
- Work continues on a Xen port for the RISC-V architecture.
Source: opennet.ru