Xen Project 4.11 Feature List
I am pleased to announce the release of the Xen Project Hypervisor 4.11. One of our long-term development goals since the introduction of Xen Project Hypervisor 4.8 has been to create a cleaner architecture for core technology, less code and a smaller computing base for security and performance. The Xen 4.11 release has followed this approach by delivering more PVH related functionality: PVH Dom0 support is now available as experimental feature and support for running unmodified PV guests in a PVH Container has been added. In addition, significant chunks of the ARM port have been rewritten.
Mitigations against Cache Side-channel Attacks
This release contains mitigations for the Meltdown and Spectre vulnerabilities. It is worth noting that we spent a significant amount of time on completing and optimizing fixes for Meltdown and Spectre vulnerabilities. Xen 4.11 contains the following mitigations.
XPTI
We implemented performance optimized XPTI, Xen's equivalent to KPTI. It is worth noting that only “classic PV” guests need XPTI whereas HVM and PVH can't attack the hypervisor via Meltdown.
Branch Predictor Hardening
For x86 CPUs, we added a new framework for Intel and AMD microcode related to Spectre mitigations as well as support for Retpoline. By default, Xen will pick the most appropriate mitigations based on compiled in support, loaded microcode, and hardware details, and will virtualise appropriate mitigations for guests to use. Command line controls via the spec-ctrl command line option are available. SP4 (Speculative Store Bypass) mitigations are also available to enable guest software to protect against within-guest information leaks via spec-ctrl=ssbd. In addition, mitigation for Lazy FP state restore ( INTEL-SA-00145) are available via spec-ctrl=eager-fpu.
Arm32: Mitigation for Cortex-A15, Cortex-A12, Cortex-A17 are present in Xen 4.7 and later with some caveats (update on the firmware).
Arm64: A PSCI-based mitigation framework for Spectre type vulnerabilities was introduced including concrete mitigations for Cortex-A57, A72, A73 and A75 CPUs for Xen 4.7 to Xen 4.9. An SMCCC 1.1 based mitigation is available for Cortex-A57, Cortex-A72, Cortex-A72, Cortex-A75 for Xen 4.10 and later.
A key motivation behind PVH was to combine the best of PV and HVM mode, to simplify the interface between operating systems with Xen Support and the Xen Hypervisor and to reduce the attack surface of Xen. This led to the current implementation of PVH. PVH guests are lightweight HVM guests which use Hardware virtualization support for memory and privileged instructions, PV drivers for I/O and native operating system interfaces for everything else. PVH also does not require QEMU.
PVH Dom0
Xen 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Up to now, the only guest type that was capable running as Dom0, were PV guests. HVM guests require QEMU to run in Dom0 to provide some emulated services to the guest, which makes HVM guests unsuitable to run as Dom0 as QEMU is not running when Dom0 boots. PVH guests, in contrast, require no support from anything other than the hypervisor, so it can boot with no other guests running and can take on the responsibilities of Dom0. Running a PVH Dom0 increases security of Xen based systems by removing approximately 1.5 million lines of QEMU code from Xen's trusted computing base.
Note that enabling a PVH Dom0 requires a PVH Dom0 capable Linux or FreeBSD. Patches for each operating system have been developed and are currently being upstreamed and should be available in the next Linux and FreeBSD versions.
PCI config space emulation in Xen
In Xen 4.11 support for the PCI configuration space has been moved from QEMU to the Hypervisor. Besides enabling PVH Dom0 support, this code will eventually also be available to HVM guests and PVH guests: however, additional security hardening needs to be performed before exposing such functionality to security supported guest types such as PVH or HVM guests.
PV in PVH container (or short: PVH Shim)
Support to run unmodified legacy PV-only guest to be run in PVH mode has been added in Xen 4.11. This allows cloud providers to support old, PV-only distros while only providing support for a single kind of guest (PVH). This simplifies management, reduces the surface of attack significantly, and eventually allows end-users to build a Xen hypervisor configuration with no “classic” PV support at all.
Next Steps
In subsequent releases, you should expect PVH Dom0 to become a supported feature and for PCI passthrough to be enabled in PVH guests. In addition, we will add the capability to compile PV-only and HVM-only versions of Xen.
Other Features
Scheduler Optimizations: Credit1 and Credit2 scheduling decisions when a vCPU is exclusively pinned to a pCPU or when soft-affinity is used have been performance optimised.
Add DMOPs to allow use of VGA with restricted QEMU (x86): Xen 4.9 introduced the Device Model Operation Hypercall (DMOPs) which significantly limits the capability of a compromised QEMU to attack the hypervisor. In Xen 4.11 we added DMOPs that enable the usage of the VGA console, which was previously restricted.
Enable Memory Bandwidth Allocation in Xen (Intel Skylake or newer): Xen 4.11 adds support for Memory Bandwidth Allocation (MBA), that allows Xen to slow misbehaving VMs by using a credit-based throttling mechanism.
Emulator enhancements (x86): support for previously unsupported Intel AVX and AVX2, and for AMD F16C, FMA4, FMA, XOP and 3DNow! instructions have been added to to the x86 emulator.
Guest resource mapping (x86): support for directly mapping Grant tables and IOREQ server pages have been introduced into Xen to improve performance.
Clean-up and future-proofing (Arm): Xen's VGIC support has been re-implemented. In addition, stage-2 page table handling, memory subsystems and big.LITTLE support have been refactored to make it easier to maintain and update the code in future.
Support for PSCI 1.1 and SMCCC 1.1 compliance (Arm): Xen has been updated to comply with the latest versions of the Arm® Power State Coordination Interface and Secure Monitor Call Calling Conventions that provides an optimised calling convention and optional, discoverable support for mitigating Spectre Variant 2.
