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.
Xen-Version: 4.11
Initial-Release: 2018-07-10
Supported-Until: 2020-01-10
Security-Support-Until: 2021-07-10Status: SupportedStatus: SupportedStatus: SupportedStatus, x86: SupportedStatus, x86: SupportedStatus, x86 PV: Supported
Status, ARM: ExperimentalStatus: Tech PreviewStatus, AMD IOMMU: Supported
Status, Intel VT-d: Supported
Status, ARM SMMUv1: Supported, not security supported
Status, ARM SMMUv2: Supported, not security supportedExtension to the GICv3 interrupt controller to support MSI.
Status: ExperimentalTraditional Xen PV guest
No hardware requirements
Status: SupportedFully virtualised guest using hardware virtualisation extensions
Requires hardware virtualisation support (Intel VMX / AMD SVM)
Status, domU: SupportedPVH 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.
Requires hardware virtualisation support (Intel VMX / AMD SVM).
Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU).
Status, domU: Supported
Status, dom0: ExperimentalARM only has one guest type at the moment
Status: SupportedStatus: SupportedFormat which the toolstack accepts for direct-boot kernels
Supported, x86: bzImage, ELF
Supported, ARM32: zImage
Supported, ARM64: ImageStatus, SysV: Supported
Status, systemd: Supported
Status, BSD-style: SupportedOutput of information in machine-parseable JSON format
Status: ExperimentalStatus, Linux: SupportedStatus: SupportedStatus: SupportedStatus: Supported, Security support externalStatus, NS16550: Supported
Status, EHCI: Supported
Status, Cadence UART (ARM): Supported
Status, PL011 UART (ARM): Supported
Status, Exynos 4210 UART (ARM): Supported
Status, OMAP UART (ARM): Supported
Status, SCI(F) UART: SupportedThese 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.
Status: Supported, not security supportedXen command-line flag to force synchronous console output.
Status: Supported, not security supportedUseful for debugging, but not suitable for production environments due to incurred overhead.
Status, x86: Supported, not security supportedDebugger to debug ELF 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.
Status: SupportedTool to capture Xen trace buffer data
Status, x86: SupportedExport hypervisor coverage data suitable for analysis by gcov or lcov.
Status: Supported, Not security supportedAllows a guest to add or remove memory after boot-time. This is typically done by a guest kernel agent known as a “balloon driver”.
Status: SupportedThis is a mechanism that allows normal operating systems with only a balloon driver to boot with memory < maxmem.
Status, x86 HVM: SupportedAllow sharing of identical pages between guests
Status, x86 HVM: ExpermentalAllow pages belonging to guests to be paged to disk
Status, x86 HVM: ExperimenalTranscendent 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.
Status: ExperimentalAllows external monitoring of hypervisor memory by maintaining multiple physical to machine (p2m) memory mappings.
Status, x86 HVM: Tech Preview
Status, ARM: Tech PreviewGroups physical cpus into distinct groups called “cpupools”, with each pool having the capability of using different schedulers and scheduling properties.
Status: SupportedA weighted proportional fair share virtual CPU scheduler. This is the default scheduler.
Status: SupportedA general purpose scheduler for Xen, designed with particular focus on fairness, responsiveness, and scalability
Status: SupportedA soft real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts
Status: ExperimentalA periodically repeating fixed timeslice scheduler.
Status: SupportedCurrently only single-vcpu domains are supported.
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.
Status: ExperimentalEnables NUMA aware scheduling in Xen
Status, x86: SupportedNB 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.
This feature is independent of the ARM “page granularity” feature (see below).
Status, x86 HVM/PVH, HAP: Supported
Status, x86 HVM/PVH, Shadow, 2MiB: Supported
Status, ARM: SupportedOn x86 in shadow mode, only 2MiB (L2) superpages are available; furthermore, they do not have the performance characteristics of hardware superpages.
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.
Status: SupportedStatus: ExperimentalStatus: ExperimentalForward Machine Check Exceptions to appropriate guests
Status: SupportedGuest-side driver capable of speaking the Xen PV block protocol
Status, Linux: Supported
Status, FreeBSD: Supported, Security support external
Status, NetBSD: Supported, Security support external
Status, OpenBSD: Supported, Security support external
Status, Windows: SupportedGuest-side driver capable of speaking the Xen PV networking protocol
Status, Linux: Supported
Status, FreeBSD: Supported, Security support external
Status, NetBSD: Supported, Security support external
Status, OpenBSD: Supported, Security support external
Status, Windows: SupportedGuest-side driver capable of speaking the Xen PV Framebuffer protocol
Status, Linux (xen-fbfront): SupportedGuest-side driver capable of speaking the Xen PV console protocol
Status, Linux (hvc_xen): Supported
Status, FreeBSD: Supported, Security support external
Status, NetBSD: Supported, Security support external
Status, Windows: SupportedGuest-side driver capable of speaking the Xen PV keyboard protocol. Note that the “keyboard protocol” includes mouse / pointer support as well.
Status, Linux (xen-kbdfront): SupportedStatus, Linux: SupportedStatus, Linux: Supported, with caveatsNB that while the PV SCSI frontend is in Linux and tested regularly, there is currently no xl support.
Guest-side driver capable of speaking the Xen PV TPM protocol
Status, Linux (xen-tpmfront): Tech PreviewGuest-side driver capable of speaking the Xen 9pfs protocol
Status, Linux: Tech PreviewGuest-side driver capable of making pv system calls
Status, Linux: Tech PreviewFor host-side virtual device support, “Supported” and “Tech preview” include xl/libxl support unless otherwise noted.
Host-side implementations of the Xen PV block protocol.
Status, Linux (xen-blkback): Supported
Status, QEMU (xen_disk), raw format: Supported
Status, QEMU (xen_disk), qcow format: Supported
Status, QEMU (xen_disk), qcow2 format: Supported
Status, QEMU (xen_disk), vhd format: Supported
Status, FreeBSD (blkback): Supported, Security support external
Status, NetBSD (xbdback): Supported, security support external
Status, Blktap2, raw format: Deprecated
Status, Blktap2, vhd format: DeprecatedBackends only support raw format unless otherwise specified.
Host-side implementations of Xen PV network protocol
Status, Linux (xen-netback): Supported
Status, FreeBSD (netback): Supported, Security support external
Status, NetBSD (xennetback): Supported, Security support externalHost-side implementation of the Xen PV framebuffer protocol
Status, QEMU: SupportedHost-side implementation of the Xen PV console protocol
Status: SupportedHost-side implementation of the Xen PV keyboard protocol. Note that the “keyboard protocol” includes mouse / pointer support as well.
Status, QEMU: SupportedHost-side implementation of the Xen PV USB protocol
Status, QEMU: SupportedStatus, Linux: ExperimentalNB that while the PV SCSI backend is in Linux and tested regularly, there is currently no xl support.
Status: Tech PreviewStatus, QEMU: Tech PreviewStatus, Linux: ExperimentalPVCalls backend has been checked into Linux, but has no xl support.
Status: Supported“Driver domains” means allowing non-Domain 0 domains with access to physical devices to act as back-ends.
Status: Supported, with caveatsSee the appropriate “Device Passthrough” section for more information about security support.
Status: Supported, with caveatsVulnerabilities of a device model stub domain to a hostile driver domain (either compromised or untrusted) are excluded from security support.
Status: ExperimentalStatus, x86: Supported
Status, ARM: ExperimentalCompile time disabled for ARM by default.
Status, x86: Supported, not security supportedStatus: ExperimentalCompile time disabled by default.
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.
Status: ExperimentalThe default policy includes FLASK labels and roles for a “typical” Xen-based system with dom0, driver domains, stub domains, domUs, and so on.
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).
Status, x86 Xen HVM: Tech PreviewThis 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.
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.
Status, x86 HVM: ExperimentalVirtual Performance Management Unit for HVM guests
Status, x86: Supported, Not security supportedDisabled by default (enable with hypervisor command line option). This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
Status, x86 PV: Supported, with caveats
Status, x86 HVM: Supported, with caveatsOnly systems using IOMMUs are supported.
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).
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.
Status: ExperimentalStatus: Supported, not security supportedNote that this still requires an IOMMU that covers the DMA of the device to be passed through.
Status: Supported, with caveatsNo support for QEMU backends in a 16K or 64K domain.
Status: SupportedStatus: SupportedThis section describes supported devices available in HVM mode using a qemu devicemodel (the default).
Status: Support scope restricted Note that other devices are available but not security supported.
Status, piix3: SupportedStatus, e1000: Supported
Status, rtl8193: Supported
Status, virtio-net: SupportedStatus, piix3 ide: Supported
Status, ahci: SupportedSee the section Blkback for image formats supported by QEMU.
Status, cirrus-vga: Supported
Status, stdvga: SupportedStatus, sb16: Supported
Status, es1370: Supported
Status, ac97: SupportedStatus, usbmouse: Supported
Status, usbtablet: Supported
Status, ps/2 keyboard: Supported
Status, ps/2 mouse: SupportedStatus, UART 16550A: SupportedStatus: Supported, not security supportedThe Xen Project provides an old version of qemu with modifications which enable use as a device model stub domain. The old version is normally selected by default only in a stub dm configuration, but it can be requested explicitly in other configurations, for example in xl with device_model_version="QEMU_XEN_TRADITIONAL".
Status, Device Model Stub Domains: Supported, with caveats
Status, as host process device model: No security support, not recommendedqemu-xen-traditional is security supported only for those available devices which are supported for mainstream QEMU (see above), with trusted driver domains (see Device Model Stub Domains).
Booting a guest via PXE.
Status: Supported, with caveatsPXE 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.
Booting a guest via guest BIOS firmware
Status, SeaBIOS (qemu-xen): Supported
Status, ROMBIOS (qemu-xen-traditional): SupportedOVMF firmware implements the UEFI boot protocol.
Status, qemu-xen: SupportedThis 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.
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.
Each Status value corresponds to levels of security support, testing, stability, etc., as follows:
Functional completeness: No
Functional stability: Here be dragons
Interface stability: Not stable
Security supported: NoFunctional completeness: Yes
Functional stability: Quirky
Interface stability: Provisionally stable
Security supported: NoFunctional completeness: Yes
Functional stability: Normal
Interface stability: Yes
Security supported: YesFunctional completeness: Yes
Functional stability: Quirky
Interface stability: No (as in, may disappear the next release)
Security supported: YesAll 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”.
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?
What is the risk of it exhibiting bugs?
General answers to the above:
Here be dragons
Pretty likely to still crash / fail to work. Not recommended unless you like life on the bleeding edge.
Quirky
Mostly works but may have odd behavior here and there. Recommended for playing around or for non-production use cases.
Normal
Ready for production use
If I build a system based on the current interfaces, will they still work when I upgrade to the next version?
Not stable
Interface is still in the early stages and still fairly likely to be broken in future updates.
Provisionally stable
We’re not yet promising backwards compatibility, but we think this is probably the final form of the interface. It may still require some tweaks.
Stable
We will try very hard to avoid breaking backwards compatibility, and to fix any regressions that are reported.
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:
Supported, Not security supported
Functionally complete, normal stability, interface stable, but no security support
Supported, Security support external
This feature is security supported by a different organization (not the XenProject). See External security support below.
Supported, with caveats
This feature is security supported only under certain conditions, or support is given only for certain aspects of the feature, or the feature should be used with care because it is easy to use insecurely without knowing it. Additional details will be given in the description.
Not all features interact well with all other features. Some features are only for HVM guests; some don’t work with migration, &c.
The XenProject security team provides security support for XenProject projects.
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.
QEMU https://wiki.qemu.org/index.php/SecurityProcess
Libvirt https://libvirt.org/securityprocess.html
FreeBSD https://www.freebsd.org/security/
NetBSD http://www.netbsd.org/support/security/
OpenBSD https://www.openbsd.org/security.html