Xen Project Hypervisor and related components (Standard)
Standard version of the Xen Project Hypervisor. Uses forks of QEMU, SeaBIOS, OVMF and iPXE provided by the Xen Project. This provides the vanilla Xen experience, but wastes space and build time. A typical NixOS setup that runs lots of VMs will usually need to build two different versions of QEMU when using this Xen derivation (one fork and upstream).
Includes:
xen.efi: The Xen Project's EFI binary, available on thebootoutput of this package.qemu-xen: The Xen Project's mirror of QEMU.seabios-xen: The Xen Project's mirror of SeaBIOS.ovmf-xen: The Xen Project's mirror of OVMF.ipxe-xen: The Xen Project's pinned version of iPXE.
This Xen Project Hypervisor (4.19.0) has been patched against the following known security vulnerabilities:
Xen Security Advisory #460: Error handling in x86 IOMMU identity mapping.
Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to.
Fixes:
Xen Security Advisory #461: PCI device pass-through with shared resources.
When multiple devices share resources and one of them is to be passed through to a guest, security of the entire system and of respective guests individually cannot really be guaranteed without knowing internals of any of the involved guests. Therefore such a configuration cannot really be security-supported, yet making that explicit was so far missing.
Fixes:
Xen Security Advisory #462: x86: Deadlock in vlapic_error().
In x86's APIC (Advanced Programmable Interrupt Controller) architecture, error conditions are reported in a status register. Furthermore, the OS can opt to receive an interrupt when a new error occurs.
It is possible to configure the error interrupt with an illegal vector, which generates an error when an error interrupt is raised.
This case causes Xen to recurse through vlapic_error(). The recursion itself is bounded; errors accumulate in the the status register and only generate an interrupt when a new status bit becomes set.
However, the lock protecting this state in Xen will try to be taken recursively, and deadlock.
Fixes: