Xen Project 4.14 Feature List

From Xen
Revision as of 14:40, 24 July 2020 by Xadimgnik (talk | contribs) (General features)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Major Features


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.

Livepatch: 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.

General features

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.

KDD support for Windows 7, 8.x and 10

kdd is a utility that communicates with a Windows Debugger instance (WinDbg or KD) and such that a domain running Windows can be debugged without enabling debug support in the guest OS itself.

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.

Other improvements

  • 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

Ongoing Work

There are several long-term features making steady progress these include:

Secret-free Xen

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.

Golang bindings

There is an ongoing effort to make first-class Golang bindings for libxl.

Change Logs

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