|Public release ||2016-02-17 12:00|
|Updated ||2016-02-17 12:25|
|Title ||x86: inconsistent cachability flags on guest mappings|
Filesadvisory-154.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-2270 / XSA-154
x86: inconsistent cachability flags on guest mappings
UPDATES IN VERSION 3
Clarify cumbersome Resolution wording.
The patch now adds a command line option to overcome the possible
performance regression. Add patch backports.
Clarify origin of assertion (at start of patch description) that
inconsistent cacheability is a problem only for mmio pages.
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.
A malicious guest administrator might be able to cause a reboot,
denying service to the entire host.
All Xen versions are affected.
Only x86 guests given control over some physical device can trigger
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.
Not handing physical devices to guests will also avoid this issue.
This issue was discovered by Jan Beulich of SUSE.
We believe that the attached patch fixes the issue. However, no
formal description of CPU behaviour in particular use cases has been
provided by Intel. There has been no response from AMD.
We are aware of a potential performance regression with this patch on
some systems - even if no hardware passthrough is configured. This is
due to the behaviour of some drivers and peripherals that is beyond
the scope of this security fix. The patch adds a command line option
"mmio-relax" to overcome this possible regression for Domain 0 or all
para-virtual guests. Note however that enabling this workaround will
reinstate the security issue these patches aim to address.
xsa154-4.6.patch Xen 4.6.x
xsa154-4.5.patch Xen 4.5.x
xsa154-4.4.patch Xen 4.4.x
xsa154-4.3.patch Xen 4.3.x
$ sha256sum xsa154*
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
(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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team