What's new in Xen 4.12

I am pleased to announce the release of Xen Project Hypervisor 4.12. This latest release adds impressive feature improvements around security and code size, x86 architectural renewal (one of our long-term development goals since Xen 4.8) and some significant updates making Xen the technology ideal for mixed-criticality systems, which is important for many use-cases covering the embedded, security and automotive industries.

The leaner architecture in Xen 4.12 reduces code size on x86 (between 5% and 22% depending on configuration) and almost 30% on Arm, reducing the potential for security vulnerabilities while making Xen an attractive option for use in mixed-criticality systems. This version of Xen is more configurable, significantly reducing integration costs for business and organizations which customize Xen heavily.

Security & Code Size

The Xen 4.12 release builds upon the security features of previous releases, continuing Xen’s legacy of being the safest and most stable hypervisor for security-focused environments.

  • HVM/PVH and PV only Hypervisor: The new Xen Project 4.12 release separates the HVM/PVH and PV code paths in Xen and provides KCONFIG options to build a PV only or HVM/PVH only hypervisor. This enables Xen based security products such as Qubes OS, Star Lab Crucible, & OpenXT to build products with vastly reduced memory footprints and attack surface more easily. In addition, the release enables cloud and hosting providers which do not offer support for PV guests to deploy HVM/PVH only hypervisors which in turn, increases security.
  • QEMU Deprivilege (DM_RESTRICT): The Xen 4.9 – 4.11 releases laid the groundwork for the QEMU Deprivilege, limiting the impact of security vulnerabilities that originate QEMU. In Xen 4.12, this feature has been vastly improved. The majority of restrictions and features have been implemented, improving security and readiness for wide-scale testing. Support for VM migration has also been added and defense-in-depth techniques using chroot, RLIMITs, and Linux namespaces which are used to protect against privilege escalations from QEMU to Xen and VM’s.
  • Argo – Hypervisor-Mediated data eXchange: Argo is a new inter-domain communication mechanism that is designed for security, safety and mixed-criticality systems with isolation properties that go beyond those of existing inter-domain communication mechanisms. Argo is designed to be robust and simple to use correctly, securely and safely. In addition, Argo meets requirements for performance isolation between domains, to prevent negative performance impact from malicious or disruptive activity of other domains, or even other VCPUs of the same domain. It follows Multiple Independent Levels of Security/Safety (MILS) architecture foundational principles. Argo provides Xen hypervisor primitives to transmit data between VMs, by performing data copies into receive memory rings registered by domains. It does not require memory sharing between VMs and does not use grant tables or Xenstore.
  • Improvements to Virtual Machine Introspection: The VMI subsystem which allows detection of 0-day vulnerabilities has seen many functional and performance improvements. Altp2m (see https://xenproject.org/tag/alt2pm/) and Intel #VE/VMFUNC support within the subsystem have been tuned and hardened. These two technologies reduce the performance overhead of Virtual Machine Introspection by 5% to 20% depending on workload.

x86 Architectural Renewal

The new Xen 4.12 features renew how x86 architecture support is implemented in Xen, a multi-year effort that is nearing completion.

  • Credit 2 Scheduler: The Credit2 scheduler is now the Xen Project default scheduler. This Credit2 scheduler represents several years worth of effort to create the next-generation scheduler for Xen. It is designed specifically for performance of latency-sensitive workloads, as well as scalability and predictability.
  • PVH Support: Grub2 boot support has been added to Xen and Grub2. These additions enable users to boot any PVH guest kernel via the grub menu. The updates to PHV also improves its stability.
  • PVH Dom0: PVH Dom0 support has now been upgraded from experimental to tech preview. This upgrade, exclusive to Intel Hardware, resolves various bugs and features several improvements such as the new dom0-iommu=map-reserved option which can be used to work around broken firmware when using a PVH Dom0. Support for migrating domUs from a PVH dom0 has also been included.

Embedded/Automotive

The Project is working to make Xen more easily safety certifiable targeting embedded and automotive use-cases. These new upgrades will increase the viability of Xen for use in mixed-criticality systems.

  • Dom0less VMs for statically partitioned systems: The new Xen 4.12 upgrade makes it possible to create and boot Arm VMs from Device Tree immediately after starting Xen. In traditional Xen environments, VMs can only be started after Dom0 kernel, user space and the toolstack are up and running. The upgrade decreases boot time by more than 90%. Dom0less VMs extend the usage of Xen to statically partitioned mixed-criticality systems. Xen is planning on extending the concept of Dom0less in subsequent releases to allow building Xen Systems entirely without a Dom0. This, in turn, will reduce the cost of safety certification significantly.
  • Tiny Arm Configurations: The Xen 4.12 upgrade allows users to build a tiny Arm configuration with less than 50 KSLOC, which in turn reduces the cost of safety certification for Xen based systems. This new functionality allows building Xen variants for specific hardware such as Renesas RCar 3 and Xilinx Ultrascale+ MPSoC with a minimal set of drivers and features that are needed for mixed-criticality systems.

Additional Technical Features

  • The new Xen 4.12 upgrade also includes improved IOMMU mapping code, which is designed to significantly improve the startup times of AMD EPYC based systems.
  • The upgrade also features Automatic Dom0 Sizing which allows the setting of Dom0 memory size as a percentage of host memory (e.g. 10%) or with an offset (e.g. 1G+10%).

Comments from Xen Project Users and Contributors:

Apertus Solutions

“With today’s introduction of the hypervisor-mediated exchange protocol Argo, Non-bypassable and Always-invoked (NEAT) properties are now possible with the Xen hypervisor,” said Daniel P. Smith, Chief Technologist at Apertus Solutions. “Early separation kernel concepts were defined in the 1980’s by John Rushby’s seminal work, extended by Jim Alves-Foss for virtual systems, and distilled into NEAT properties for Multiple Independent Levels of Separation (MILS) systems. Apertus Solutions looks forward to future Xen Security Modules (XSM) type assertion capabilities that only a hypervisor-mediated exchange protocol like Argo can deliver on a per-message basis, on the trusted computing foundations of DRTM, TrenchBoot, disaggregated Xen and OpenXT.”

Assured Information Security

“Argo is a robust inter-VM communication protocol for Xen with emphasis on security and isolation for trusted systems,” said Rich Turner, Principal Engineer, SecureView, Assured Information Security. “Assured Information Security (AIS) is committed to advancing the support and implementation of Argo in secure products and services. As long-standing supporters and contributors of OpenXT, AIS is excited by the security advancements that Argo provides to Xen and downstream projects like OpenXT. Our customers count on secure isolation and communication within our products and Argo will further our ability to deliver secure, safe, and mission-critical products.”

Bitdefender

“As a member of the Advisory Board, we are fully committed to supporting Xen Project. We are impressed with the technological advancements the Xen Project team introduced with the Xen 4.12 release and look forward to contributing to the future success of the project,” said Mihai Donțu, Chief Linux Officer at Bitdefender. “The new functionality developed in Virtual Machine Introspection (VMI) is enhancing the overall performance of purposely built security solutions that take advantage of this subsystem. Bitdefender Hypervisor Introspection is leveraging the VMI subsystem to defend virtual machines against zero-day exploits and is using Altp2m and #VE to improve the solution performance.”

Citrix

“With its 4.12 release, the Xen Project Hypervisor builds upon its already strong foundations of dependable workload isolation and cutting edge security features,” said James Bulpin, Senior Director, Technology. Citrix. “By delivering on QEMU de-privilege, and enabling integrators to optionally exclude code for unused virtualization modes, Xen 4.12 exhibits valuable defense-in-depth, and attack surface minimization qualities. These capabilities enable Citrix Hypervisor, which uses Xen at its core, to deliver dependable security to our cloud, server, and desktop virtualization customers.”

DornerWorks

“As a long time proponent of embedded virtualization for commercial and safety-critical applications, DornerWorks is excited by the continued focus of the Xen community on not only large server clusters but also on the smaller embedded systems that we rely on every day,” said Steven H. VanderLeest, Ph.D, Chief Operating Officer at DornerWorks. “We are especially pleased with the release of Dom0less boot and configuration options to reduce ARM code size, which will help reduce the certification and maintenance burden while improving Xen’s boot time and performance.”

EPAM

“The latest release of Xen Hypervisor is the first step towards functional safety regulation compliance, reducing external non-compliant component dependency and introducing minimal code footprint configuration. These changes enable the usage of Xen Hypervisor in complex, mixed-safety automotive systems, such as digital cockpits or communication gateways,” said Alex Agizim, CTO, Automotive & Embedded Systems, EPAM.

Star Lab

“The release of Xen 4.12 enables Star Lab to continue delivering Crucible, our highly performant and secure virtualized solution for tactical virtualization,” said Irby Thompson, CEO of Star Lab. “Xen 4.12 helps reduce the size of the core hypervisor, while further isolating control logic from the guests, increasing security benefits for Star Lab and our customers. Additionally, Xen 4.12 will enable Star Lab to continue the development of hypervisor offerings for its ARM platform customers. Star Lab is looking forward to collaborating with the Xen community on additional dom0less and tiny ARM developments.”

Qubes OS

“Reducing the Xen code size, its complexity, moving more parts away from Paravirtualization (PV), and making optional features configurable at build time is hugely beneficial in terms of reducing attack surface,” said Marek Marczykowski-Górecki, Qubes OS project leader. “We look forward to using Xen 4.12 in the next Qubes OS release to even better utilize hardware virtualization and provide secure client environment.”

SUSE

“We at SUSE have been supporting Xen as a high end, reliable technology since the very beginning of virtualization support in our enterprise products, “said Jiri Kosina, Director, SUSE Labs Core. “Therefore we are very happy to see that this new hypervisor release is, once again, expanding the set of features that meet the rapidly growing demand of the current virtualization market.”

Xilinx

“Xilinx is excited to see the new features introduced by the Xen development team for the 4.12 release, especially the new Dom0-less fast boot combined with the code size reductions targeting Xilinx Zynq UltraScale+ MPSoC,” said Simon George, Director of System Software and SoC Solution Marketing at Xilinx. “These features, along with the earlier null scheduler, allow Xen to better serve diverse, embedded use cases. We look forward to Xen’s roadmap for continued work on new features for these markets.”

Summary

his release contains 1466 commits from 364 patch series. A significant number of contributions for this release of the Xen Project came from Citrix, Suse, ARM, Xilinx, BitDefender, EPAM, OpenXT Community, Oracle, Gentoo Linux, Aggios, Amazon, Invisible Things Lab and DornerWorks, and a number of universities and individuals. As in Xen 4.11, we spent a lot of energy to improve code quality and harden security. On behalf of the Xen Project Hypervisor team, I would like to thank everyone for their contributions (either in the form of patches, code reviews, bug reports or packaging efforts) to the Xen Project.

Please check our acknowledgement page, which recognises all those who helped make this release happen. The source can be located in the tree (tag RELEASE-4.12.0) or can be downloaded as a tarball from our website. For detailed download and build instructions check out the guide on building Xen 4.12.

More information can be found at

Read more

Welcome Honda to the Xen Project Board
12/09/2024

We're excited to announce our newest Advisory Board Member Honda, to Xen Project. Since its foundation, Honda has been committed to "creating a society that is useful to people" by utilizing its technologies and ideas. Honda also focuses on environmental responsiveness and traffic safety, and continue

Say hello to our new website
12/05/2024

Hello Xen Community, You may have noticed something different... We've refreshed our existing website! Why did we do this? Well, all these new changes are part of an ongoing effort to increase our visibility and make it easier to find information on pages. We know how important it

Xen Project Announces Performance and Security Advancements with Release of 4.19
08/05/2024

New release marks significant enhancements in performance, security, and versatility across various architectures.  SAN FRANCISCO – July 31st, 2024 – The Xen Project, an open source project under the Linux Foundation, is proud to announce the release of Xen Project 4.19. This release marks a significant milestone in enhancing performance, security,

Upcoming Closure of Xen Project Colo Facility
07/10/2024

Dear Xen Community, We regret to inform you that the Xen Project is currently experiencing unexpected changes due to the sudden shutdown of our colocated (colo) data center facility by Synoptek. This incident is beyond our control and will impact the continuity of OSSTest (the gating Xen Project CI loop)