Description 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](https://xenbits.xenproject.org/docs/4.19-testing/misc/efi.html), available on the `boot` output of this package.
This Xen Project Hypervisor (4.19.0) has been patched against the following known security vulnerabilities:
* [Xen Security Advisory #460](https://xenbits.xenproject.org/xsa/advisory-460.html): **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:
* [CVE-2024-31145](https://www.cve.org/CVERecord?id=CVE-2024-31145)
* [Xen Security Advisory #461](https://xenbits.xenproject.org/xsa/advisory-461.html): **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:
* [CVE-2024-31146](https://www.cve.org/CVERecord?id=CVE-2024-31146)
* [Xen Security Advisory #462](https://xenbits.xenproject.org/xsa/advisory-462.html): **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:
* [CVE-2024-45817](https://www.cve.org/CVERecord?id=CVE-2024-45817)
License
Homepage
Newest release runs on
Attribute paths
Raw data
Elsewhere