Xen Project Releases Version 4.17 with Enhanced Security, Higher Performance, Improved Embedded Static Configuration and Speculative Mitigation Support

The Xen Project, an open source hypervisor hosted at the Linux Foundation, announced the release of Xen Project Hypervisor 4.17, which introduces a variety of features allowing for safety certification, static partitioning of embedded devices, increased performance, enhanced security and improved device pass-through reliability. Thanks to the active Xen Project community, a wide range of developers from many companies and organizations contributed to this latest release.

"We are pleased to see the Xen Project community behind this proven open source hypervisor, making it the ideal choice for enterprise use cases that require advanced security features and high levels of performance," said George Dunlap, chairman of the Xen Project Advisory Board. "We will continue to expand the community initiatives the Xen Project leads and contributes to, as we work together with industry leaders and innovators."

Notable Features

• MISRA-C integration: The project has officially adopted four directives and 24 rules, added MISRA-C checker build integration, and defined how to document deviations. A number of MISRA-C violations have been fixed.
• Static configuration options for ARM: In many embedded environments, we know ahead of time exactly what resources all guests will need at boot time. In constrained resource environments, allocation on use increases the possibility that the allocation will fail at runtime. With static configuration, resources are allocated statically when the hypervisor boots, removing the possibility of runtime failure. Resources which can be statically configured as of 4.17 include event channels, shared memory, and hypervisor heap.
• ARM: Add "tech preview" implementation for VirtIO. Xen now includes full support for VirtIO on embedded systems, on ARM, for the virtio-mmio transport, allowing a wide range of VirtIO devices to be supported. This includes front-end support in Linux, toolstack (libxl/xl) and dom0less support, and a userspace backend. Currently, the following stand-alone backends are available and have been tested: virtio-disk, virtio-net, i2c, and gpio.
• dom0less / Hyperlaunch: cpupools can be specified at boot using device tree. This allows the use of cpupools in dom0less / Hyperlaunch -style configurations; in particular, it makes it possible to assign different types of CPUs of an ARM big.LITTLE system to different cpupools at boot time.
• dom0less / Hyperlaunch: PV frontend / backend connections can now be specified between guests, allowing statically booted guests with PV devices
• On ARM, p2m structures are now allocated out of a pool of memory set aside at domain creation; this provides better isolation between guests against memory resource failures
• ARM: Mitigations against Spectre-BHB
• x86: IOMMU superpage support for all guest types; improving performance of PCI pass-through
• x86: Security support hosts with up to 12 TiB of RAM
• x86: Can now set cpuid parameters for dom0 at boot time
• x86: mwait-idle support: Added SPR and ADL
• x86: Improved speculative mitigation support, including VIRT_SSBD and MSR_SPEC_CTRL features to help guests know what speculative mitigations they don't need to be done (due to mitigations on the hypervisor side), and to control what kind of speculative mitigations the hypervisor performs on their behalf
• Out-of-tree builds for the hypervisor now supported
• ARM: Since addition of Zephyr RTOS guests support (Xen 4.15, Zephyr 3.1.0), work has been done on making it possible to run Zephyr in dom0 improving boot time, stability and paving the way for future safety certification for Xen-based systems

Community Initiative Updates

VirtIO: VirtIO-Grant is VirtIO drivers using grant operations. In contrast to VirtIO-MMIO, which does direct map, virtio-grant is safer and also supports driver domains. VirtIO-Grant support has been implemented and upstreamed in Linux at the transport level. There are patches to enable it in QEMU backends and in virtio-vhost, but these have not yet been upstreamed, nor is there toolstack support (libxl / xl) yet. Both x86 and ARM will be included in the next few releases.

Hyperlaunch The vision for Hyperlaunch is to enable complete, flexible configuration of a system of running VMs at boot time, suitable for "measured launch." The first batch of functionality has been implemented, and patches sent to the list; this enables multiple PV domains to be specified, with their images handed to the hypervisor at boot. Everything necessary for these domains to come up, including the Xenstore entries required for PV devices to function, is implemented. Once the patch is upstreamed, we will be adding support for PVH devices and HVM devices for a pure "static configuration" mode (where no new domains can be created after boot), along with support for a "domB" builder domain, capable of setting up arbitrary domain configurations in a fashion suitable for measured boot.

Community Quotes

EPAM
"Support of VirtIO on ARM as a standardized I/O virtualization framework and placing thin Zephyr RTOS in control domain are important to build portable and safety-compliant compute systems in automotive," said Alex Agizim, CTO, Automotive & Embedded, EPAM Systems.

To read the full press release, click here.