| Summary: | app-emulation/xen: x86: inconsistent cachability flags on guest mappings | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | idella4, xen |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B3 [ebuild+] | ||
| Package list: | Runtime testing required: | --- | |
public release *** This bug has been marked as a duplicate of bug 574012 *** |
Xen Security Advisory XSA-154 x86: inconsistent cachability flags on guest mappings *** EMBARGOED UNTIL 2016-02-17 12:00 UTC *** ISSUE DESCRIPTION ================= Multiple mappings of the same physical page with different cachability setting can cause problems. While one category (risk of using stale data) affects only guests themselves (and hence avoiding this can be left for them to control), the other category being Machine Check exceptions can be fatal to entire hosts. According to the information we were able to gather, only mappings of MMIO pages may surface this second category, but even for them there were cases where the hypervisor did not properly enforce consistent cachability. IMPACT ====== A malicious guest administrator might be able to cause a reboot, denying service to the entire host. VULNERABLE SYSTEMS ================== All Xen versions are affected. Only x86 guests given control over some physical device can trigger this vulnerability. x86 systems are vulnerable. ARM systems are not vulnerable. The vulnerability depends on the system response to mapping the same memory with different cacheability. On some systems this is harmless; on others, depending on CPU and chipset, it may be fatal. MITIGATION ========== Not handing physical devices to guests will also avoid this issue. RESOLUTION ========== Applying the attached patch resolves this issue to the best of our knowledge. However, no formal description of CPU behavior in the cases of interest was provided to us by Intel, and no response at all was received from AMD to a respective inquiry. However, unfortunately, we are aware of a potential performance regression with this patch on some systems. This patch might cause the performance regression even if no hardware passthrough is configured This depends on the peripherals present in the system, and the behaviour of the drivers used for those peripherals. A resolution without this potential performance regression is not currently available. xsa154.patch xen-unstable, Xen 4.6.x $ sha256sum xsa154* 4c21b532ba7f00716e4155693ad25619ebc726dbe877d008f424e67df2b7fe60 xsa154.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the mitigations described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the configuration change would be visible to the guest, which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html