The adjustments made for XSA-379 as well as those subsequently becoming XSA-387 still left a race window, when a HVM or PVH guest does a grant table version change from v2 to v1 in parallel with mapping the status page(s) via XENMEMaddtophysmap. Some of the status pages may then be freed while mappings of them would still be inserted into the guest's secondary (P2M) page tables.
Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
Xen guests need to use different processor instructions to make explicit calls into the Xen hypervisor depending on guest type and/or CPU vendor. In order to hide those differences, the hypervisor can fill a hypercall page with the needed instruction sequences, allowing the guest operating system to call into the hypercall page instead of having to choose the correct instructions.
The hypercall page contains whole functions, which are written by the hypervisor and executed by the guest. With the lack of an interface between the guest OS and the hypervisor specifying how a potential modification of those functions should look like, the Xen hypervisor has no knowledge how any potential mitigation should look like or which hardening features should be put into place.
This results in potential vulnerabilities if the guest OS is using any speculative mitigation that performs a compiler transform on "ret" instructions in order to work (e.g. the Linux kernel rethunk or safe-ret mitigations).
Furthermore, the hypercall page has no provision for Control-flow Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply malfunction in such configurations.
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.
Resources the sharing of which is known to be problematic include, but are not limited to - - PCI Base Address Registers (BARs) of multiple devices mapping to the same page (4k on x86), - - INTx lines.
PCI devices can make use of a functionality called phantom functions, that when enabled allows the device to generate requests using the IDs of functions that are otherwise unpopulated. This allows a device to extend the number of outstanding requests.
Such phantom functions need an IOMMU context setup, but failure to setup the context is not fatal when the device is assigned. Not failing device assignment when such failure happens can lead to the primary device being assigned to a guest, while some of the phantom functions are assigned to a different domain.
PHYSDEVOPmappirq with MAPPIRQTYPEGSI does not range check map->index.
A malicious HVM guest kernel can crash the host. It might also be able to read hypervisor or guest memory.
All Xen systems running HVM guests are vulnerable. PV guests are not vulnerable.
Acknowledgements:
Red Hat would like to thank the Xen project for reporting this issue. Upstream acknowledges Matthew Daley as the original reporter.