Support statement for this release

1 Release Support
2 Feature Support
3 Format and definitions

This document describes the support status and in particular the security support status of the Xen branch within which you find it.

See the bottom of the file for the definitions of the support status levels etc.

1 Release Support

2 Feature Support

2.1 Kconfig

EXPERT and DEBUG Kconfig options are not security supported. Other Kconfig options are supported, if the related features are marked as supported in this document.

2.2 Host Architecture

2.2.1 x86-64

2.2.2 ARM v7 + Virtualization Extensions

2.2.3 ARM v8

2.3 Host hardware support

2.3.1 Physical CPU Hotplug

2.3.2 Physical Memory Hotplug

2.3.3 Host ACPI (via Domain 0)

2.3.4 x86/Intel Platform QoS Technologies

2.3.5 IOMMU

2.3.6 ARM/GICv3 ITS

2.4 Guest Type

2.4.1 x86/PV

2.4.2 x86/HVM

2.4.3 x86/PVH

PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. During development this was sometimes called HVMLite or PVHv2.

2.4.4 ARM

2.5 Toolstack

2.5.1 xl

2.5.2 Direct-boot kernel image format

2.5.3 Dom0 init support for xl

2.5.4 JSON output support for xl

2.5.5 Open vSwitch integration for xl

2.5.6 Virtual cpu hotplug

2.5.7 QEMU backend hotplugging for xl

2.6 Toolstack/3rd party

2.6.1 libvirt driver for xl

2.7 Debugging, analysis, and crash post-mortem

2.7.1 Host serial console

2.7.2 Hypervisor 'debug keys'

These are functions triggered either from the host serial console, or via the xl 'debug-keys' command, which cause Xen to dump various hypervisor state to the console.

2.7.3 Hypervisor synchronous console output (sync_console)

Useful for debugging, but not suitable for production environments due to incurred overhead.

2.7.4 gdbsx

2.7.5 Soft-reset for PV guests

Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state, but with all the memory from the previous state of the VM intact. This is primarily designed to allow "crash kernels", which can do core dumps of memory to help with debugging in the event of a crash.

2.7.6 xentrace

2.7.7 gcov

2.8 Memory Management

2.8.1 Dynamic memory control

Allows a guest to add or remove memory after boot-time. This is typically done by a guest kernel agent known as a "balloon driver".

2.8.2 Populate-on-demand memory

This is a mechanism that allows normal operating systems with only a balloon driver to boot with memory < maxmem.

2.8.3 Memory Sharing

2.8.4 Memory Paging

2.8.5 Transcendent Memory

Transcendent Memory (tmem) allows the creation of hypervisor memory pools which guests can use to store memory rather than caching in its own memory or swapping to disk. Having these in the hypervisor can allow more efficient aggregate use of memory across VMs.

2.8.6 Alternative p2m

Alternative p2m (altp2m) allows external monitoring of guest memory by maintaining multiple physical to machine (p2m) memory mappings.

2.9 Resource Management

2.9.1 CPU Pools

Groups physical cpus into distinct groups called "cpupools", with each pool having the capability of using different schedulers and scheduling properties.

2.9.2 Credit Scheduler

A weighted proportional fair share virtual CPU scheduler. This is the default scheduler.

2.9.3 Credit2 Scheduler

A general purpose scheduler for Xen, designed with particular focus on fairness, responsiveness, and scalability

2.9.4 RTDS based Scheduler

A soft real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts

2.9.5 ARINC653 Scheduler

2.9.6 Null Scheduler

A very simple, very static scheduling policy that always schedules the same vCPU(s) on the same pCPU(s). It is designed for maximum determinism and minimum overhead on embedded platforms.

2.9.7 NUMA scheduler affinity

2.10 Scalability

2.10.1 Super page support

NB that this refers to the ability of guests to have higher-level page table entries point directly to memory, improving TLB performance. On ARM, and on x86 in HAP mode, the guest has whatever support is enabled by the hardware.

On x86 in shadow mode, only 2MiB (L2) superpages are available; furthermore, they do not have the performance characteristics of hardware superpages.

2.10.2 x86/PVHVM

This is a useful label for a set of hypervisor features which add paravirtualized functionality to HVM guests for improved performance and scalability. This includes exposing event channels to HVM guests.

2.11 High Availability and Fault Tolerance

2.11.1 Remus Fault Tolerance

2.11.2 COLO Manager

2.11.3 x86/vMCE

2.12 Virtual driver support, guest side

2.12.1 Blkfront

2.12.2 Netfront

2.12.3 PV Framebuffer (frontend)

2.12.4 PV Console (frontend)

2.12.5 PV keyboard (frontend)

Guest-side driver capable of speaking the Xen PV keyboard protocol. Note that the "keyboard protocol" includes mouse / pointer support as well.

2.12.6 PV USB (frontend)

2.12.7 PV SCSI protocol (frontend)

NB that while the PV SCSI frontend is in Linux and tested regularly, there is currently no xl support.

2.12.8 PV TPM (frontend)

2.12.9 PV 9pfs frontend

2.12.10 PVCalls (frontend)

2.13 Virtual device support, host side

For host-side virtual device support, "Supported" and "Tech preview" include xl/libxl support unless otherwise noted.

2.13.1 Blkback

2.13.2 Netback

2.13.3 PV Framebuffer (backend)

2.13.4 PV Console (xenconsoled)

2.13.5 PV keyboard (backend)

Host-side implementation of the Xen PV keyboard protocol. Note that the "keyboard protocol" includes mouse / pointer support as well.

2.13.6 PV USB (backend)

2.13.7 PV SCSI protocol (backend)

NB that while the PV SCSI backend is in Linux and tested regularly, there is currently no xl support.

2.13.8 PV TPM (backend)

2.13.9 PV 9pfs (backend)

2.13.10 PVCalls (backend)

2.13.11 Online resize of virtual disks

2.14 Security

2.14.1 Driver Domains

"Driver domains" means allowing non-Domain 0 domains with access to physical devices to act as back-ends.

See the appropriate "Device Passthrough" section for more information about security support.

2.14.2 Device Model Stub Domains

Vulnerabilities of a device model stub domain to a hostile driver domain (either compromised or untrusted) are excluded from security support.

2.14.3 Device Model Deprivileging

This means adding extra restrictions to a device model in order to prevent a compromised device model from attacking the rest of the domain it's running in (normally dom0).

"Tech preview with limited support" means we will not issue XSAs for the additional functionality provided by the feature; but we will issue XSAs in the event that enabling this feature opens up a security hole that would not be present without the feature disabled.

For example, while this is classified as tech preview, a bug in libxl which failed to change the user ID of QEMU would not receive an XSA, since without this feature the user ID wouldn't be changed. But a change which made it possible for a compromised guest to read arbitrary files on the host filesystem without compromising QEMU would be issued an XSA, since that does weaken security.

2.14.4 KCONFIG Expert

2.14.5 Live Patching

2.14.6 Virtual Machine Introspection

2.14.7 XSM & FLASK

Also note that using XSM to delegate various domain control hypercalls to particular other domains, rather than only permitting use by dom0, is also specifically excluded from security support for many hypercalls. Please see XSA-77 for more details.

2.14.8 FLASK default policy

The default policy includes FLASK labels and roles for a "typical" Xen-based system with dom0, driver domains, stub domains, domUs, and so on.

2.15 Virtual Hardware, Hypervisor

2.15.1 x86/Nested PV

This means running a Xen hypervisor inside an HVM domain on a Xen system, with support for PV L2 guests only (i.e., hardware virtualization extensions not provided to the guest).

This works, but has performance limitations because the L1 dom0 can only access emulated L1 devices.

Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare), but nobody has reported on performance.

2.15.2 x86/Nested HVM

This means providing hardware virtulization support to guest VMs allowing, for instance, a nested Xen to support both PV and HVM guests. It also implies support for other hypervisors, such as KVM, Hyper-V, Bromium, and so on as guests.

2.15.3 vPMU

Disabled by default (enable with hypervisor command line option). This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html

2.15.4 x86/PCI Device Passthrough

Not compatible with migration, populate-on-demand, altp2m, introspection, memory sharing, or memory paging.

Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use this feature to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).

2.15.5 x86/Multiple IOREQ servers

An IOREQ server provides emulated devices to HVM and PVH guests. QEMU is normally the only IOREQ server, but Xen has support for multiple IOREQ servers. This allows for custom or proprietary device emulators to be used in addition to QEMU.

2.15.6 ARM/Non-PCI device passthrough

Note that this still requires an IOMMU that covers the DMA of the device to be passed through.

2.15.7 ARM: 16K and 64K page granularity in guests

2.15.8 ARM: Guest Device Tree support

2.15.9 ARM: Guest ACPI support

2.16 Virtual Hardware, QEMU

This section describes supported devices available in HVM mode using a qemu devicemodel (the default).

2.16.1 x86/Emulated platform devices (QEMU):

2.16.2 x86/Emulated network (QEMU):

2.16.3 x86/Emulated storage (QEMU):

2.16.4 x86/Emulated graphics (QEMU):

2.16.5 x86/Emulated audio (QEMU):

2.16.6 x86/Emulated input (QEMU):

2.16.7 x86/Emulated serial card (QEMU):

2.16.8 x86/Host USB passthrough (QEMU):

2.17 Virtual Firmware

2.17.1 x86/HVM iPXE

PXE inherently places full trust of the guest in the network, and so should only be used when the guest network is under the same administrative control as the guest itself.

2.17.2 x86/HVM BIOS

2.17.3 x86/HVM OVMF

3 Format and definitions

This file contains prose, and machine-readable fragments. The data in a machine-readable fragment relate to the section and subsection in which it is found.

The file is in markdown format. The machine-readable fragments are markdown literals containing RFC-822-like (deb822-like) data.

In each case, descriptions which expand on the name of a feature as provided in the section heading, precede the Status indications. Any paragraphs which follow the Status indication are caveats or qualifications of the information provided in Status fields.

3.1 Keys found in the Feature Support subsections

3.1.1 Status

This gives the overall status of the feature, including security support status, functional completeness, etc. Refer to the detailed definitions below.

If support differs based on implementation (for instance, x86 / ARM, Linux / QEMU / FreeBSD), one line for each set of implementations will be listed.

3.2 Definition of Status labels

Each Status value corresponds to levels of security support, testing, stability, etc., as follows:

3.2.1 Experimental

3.2.2 Tech Preview

3.2.2.1 Supported

3.2.2.2 Deprecated

All of these may appear in modified form. There are several interfaces, for instance, which are officially declared as not stable; in such a case this feature may be described as "Stable / Interface not stable".

3.3 Definition of the status label interpretation tags

3.3.1 Functionally complete

Does it behave like a fully functional feature? Does it work on all expected platforms, or does it only work for a very specific sub-case? Does it have a sensible UI, or do you have to have a deep understanding of the internals to get it to work properly?

3.3.2 Functional stability

3.3.3 Interface stability

If I build a system based on the current interfaces, will they still work when I upgrade to the next version?

3.3.4 Security supported

Will XSAs be issued if security-related bugs are discovered in the functionality?

If "no", anyone who finds a security-related bug in the feature will be advised to post it publicly to the Xen Project mailing lists (or contact another security response team, if a relevant one exists).

Bugs found after the end of Security-Support-Until in the Release Support section will receive an XSA if they also affect newer, security-supported, versions of Xen. However, the Xen Project will not provide official fixes for non-security-supported versions.

Three common 'diversions' from the 'Supported' category are given the following labels:

3.3.5 Interaction with other features

Not all features interact well with all other features. Some features are only for HVM guests; some don't work with migration, &c.

3.3.6 External security support

We also provide security support for Xen-related code in Linux, which is an external project but doesn't have its own security process.

External projects that provide their own security support for Xen-related features are listed below.