Xen Project Hypervisor (Without Internal Components)
Slimmed-down version of the Xen Project Hypervisor that reuses nixpkgs packages as much as possible. Instead of using the Xen Project forks for various internal components, this version uses seabios
, ovmf
and ipxe
from Nixpkgs. These components may ocasionally get out of sync with the hypervisor itself, but this builds faster and uses less space than the default derivation.
Use with qemu_xen_4_19
or qemu_xen
.
Includes:
xen.efi
: The Xen Project's EFI binary, available on theboot
output of this package.
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: