Xen Project 4.14 Feature List
- 1 Major Features
- 1.1 Security
- 1.2 General features
- 1.3 Support for new hardware
- 1.4 Other improvements
- 2 Ongoing Work
- 3 Change Logs
- 4 XSA Patch Level
Linux stubdomains (contributed by QUBES OS)
DM stubdomains are a unique Xen feature which adds another layer of protection against privilege escalation attacks (i.e., defense-in-depth). Before 4.14 however, guests using this feature were limited to using "qemu-traditional" as a devicemodel, limiting the emulated hardware available to such guests.
Linux stubomains are a refresh of the stubomain feature which allow it to use the most recent versions of QEMU, making the latest emulated hardware and other QEMU features available to guests while retaining the extra security provided by stub domains
Control-flow Enforcement Technology (CET) Shadow Stack support (contributed by Citrix)
Control-flow Enforcement Technology (CET) is a set of features in hardware designed to combat Return-oriented Programming (ROP, also call/jump COP/¯JOP) attacks. Xen 4.14 can use these hardware features, if available, to protect itself from ROP attacks.
Lightweight VM fork for fuzzing / introspection. (contributed by Intel)
This allows the very lightweight "fork" of a VM, leveraging the memsharing code. The "fork" does not have a clone of the device model, and so is mainly useful for using fuzzers like AFL to do rapid experimentation.
buildid and hotpatch stack requirements
Hotpatches can now specify that they will only apply on top of specific hypervisor build ids, and/or require specific other hotpatches to have been applied, before applying. This reduces the risks involved in applying hotpatches inappropriately, making them safer to use.
It is now possible to disable hypervisor support for 32-bit PV domains, while retaining support for 64-bit PV domains.
Hypervisor FS support
Similar to Linux’s sysfs, Hypervisor FS allows Xen to expose internal data and control knobs in a structured way, without the previous requirement of parsing log data or writing custom hypercalls to transport the data, and custom code to read it.
Running Xen as a Hyper-V Guest
Xen will now run as a guest under Hyper-V, the hypervisor developed by Microsoft which runs Microsoft’s Azure cloud. Running Xen inside a cloud allows the same VM control stack to be used on-premise as in a cloud, allowing virtual machines to be moved freely between on-prem and cloud, or even between clouds.
Domain ID randomization, persistence across save / restore
Xen now allows the creation of a domain with a random domain ID (rather than a sequential one). Additionally, Domain IDs can be requested to be preserved across save/restore/migrate. This may be useful for avoiding domain ID reuse attacks. It's also a key component of the ongoing work to allow VMs to be migrated without the cooperation of the guest operating system.
Golang binding autogeneration
Golang bindings have been significantly expanded. Golang now generates libxl structs directly from libxl's IDL; meaning all structures are generated and new ones will be generated automatically. A number of additional functions have had wrappers made, and support for domain creation has been added.
Support for new hardware
Support for Raspberry Pi 4 has been extended and now all versions of the RPI4, including the popular ones with 4GB and 8GB of RAM, work on Xen. Additionally, version 4.14 will support the next generation AMD EPYC™ processor, codenamed “Milan”, when it is available to the public.
- x2APIC mode whenever available
- Performance improvements for Xen running as a guest either under Xen or Viridian
- Migration streams: Preserving CPUID across migrate
- Emulation: More accurate per-vendor behavior, AVX512_BF16 implemented
- Switched hypervisor build to Kbuild for more robust handling, faster improvements
- Improvements to mem_sharing, altp2m, x86 boot path, microcode handling, libxl event handling, xenstore, xentop, network hotplug scripts, and many others
There are several long-term features making steady progress these include:
As a universal mitigation to Spectre-like speculative execution attacks against Xen, there is an ongoing effort underway to make sure that when handling hypercalls or emulation for one specific vcpu, that Xen *only* has access to memory owned by that vcpu. This includes removing Xen's direct map, as well as refactoring per-vcpu mappings inside of Xen to restrict what's available. When complete, this will make Xen very resistant, if not impervious, to any Spectre-like attacks against the hypervisor.
Live migration without guest cooperation
Currently, live migration of guests requires some cooperation with the guest. Guests without PV drivers, or with broken PV drivers, cannot be migrated safely. There is an ongoing effort to make it possible to migrate a guest without the guest cooperation; this means safer and easier guest management.
There is an ongoing effort to make first-class Golang bindings for libxl.
Change logs for Xen 4.14.0 can be found at
Change logs for QEMU upstream for Xen 4.14.0
Change logs for QEMU traditional for Xen 4.14.0
XSA Patch Level
Xen 4.14.0 is up-to-date up to and including XSA-329. For more information see xenbits.xenproject.org/xsa