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.
- 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 the virtual I/O device, ensuring compatibility with a wide range of VirtIO devices. Frontend support has been implemented for Linux, toolchain (libxl/xl), dom0less mode, and backends running in user space (virtio-disk, virtio-net, i2c, and gpio backends have been tested).
- Improved support for dom0less mode, which allows you to avoid deploying a dom0 environment at startup virtual machines At an early stage of server boot. The ability to define CPU pools (CPUPOOLs) at boot (via the device tree) is now available, enabling pools to be used in configurations without dom0, for example, to bind different types of CPU cores on ARM systems based on the big.LITTLE architecture, which combine powerful but power-hungry cores with less powerful but more energy-efficient cores in a single chip. Furthermore, dom0less provides the ability to bind the paravirtualization frontend/backend to guest systems, enabling guest systems to boot 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.
- The VirtIO-Grant transport is being developed separately. It differs from VirtIO-MMIO in that it offers a higher level of security and the ability to run handlers in a separate, isolated driver domain. Instead of direct memory mapping, VirtIO-Grant uses translation of guest system physical addresses into grant links, allowing the use of pre-agreed shared memory regions for data exchange between the guest system and the VirtIO backend, without granting the backend permission to perform memory mapping. Support for VirtIO-Grant is already implemented in the kernel. Linux, but is not yet included in the QEMU backends, virtio-vhost, or the toolchain (libxl/xl).
- The Hyperlaunch initiative, aimed at providing flexible tools for configuring virtual machine launches during system boot, continues to evolve. The first set of patches is now ready, enabling the detection of PV domains and the transfer of their images to the hypervisor during boot. Everything necessary for launching such paravirtualized systems has also been implemented. domains, including Xenstore components for PV drivers. Once the patches are approved, work will begin on enabling support for PVH and HVM devices, as well as implementing a separate domB (builder domain) suitable for measured boot, which verifies the validity of all loaded components.
- Work continues on a Xen port for the RISC-V architecture.
Source: opennet.ru
