[kernel-xen] Fwd: [Xen-announce] Xen Security Advisory 154 (CVE-2016-2270) - x86: inconsistent cachability flags on guest mappings
netwiz at crc.id.au
Thu Feb 18 12:07:05 AEDT 2016
I'd like to forward this for discussion to the list - as you'll notice
that I have only patched XSA-170 released today.
The patch below is somewhat interesting - as a workaround is presented
by a new option (not available in previous patch versions) to restore
the performance regression involved with this fix. The problem is, with
this option, you reintroduce the security issue that the patch resolves.
As such, it leaves us with two scenarios:
1) Apply the patch and take the performance hit (not sure of the scale
of this hit or what it affects) - even if your hardware is not
2) Use the command line option which makes this patch moot.
I wasn't able to canvas this list for opinions on this before the
embargo ended - but am interested to gather peoples feedback after
My concerns are that there is not enough quantifiable information to be
able to easily determine a way forward. There is not enough information
to make me comfortable as to what hardware is affected, what degree the
of performance loss is.
Am happy to get feedback on other peoples thoughts on this issue.
Email: netwiz at crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
-------- Original Message --------
Subject: [Xen-announce] Xen Security Advisory 154 (CVE-2016-2270) - x86:
inconsistent cachability flags on guest mappings
Date: 2016-02-17 23:28
From: Xen.org security team <security at xen.org>
To: xen-announce at lists.xen.org, xen-devel at lists.xen.org,
xen-users at lists.xen.org, oss-security at lists.openwall.com
Copy: "Xen.org security team" <security at xen.org>
-----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.
More information about the kernel-xen