Xen.org security team
2014-Aug-12 13:03 UTC
Xen Security Advisory 97 (CVE-2014-5146, CVE-2014-5149) - Long latency virtual-mmu operations are not preemptible
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2014-5146,CVE-2014-5149 / XSA-97
version 3
Long latency virtual-mmu operations are not preemptible
UPDATES IN VERSION 3
===================
Public release.
ISSUE DESCRIPTION
================
Some MMU virtualization operations on HVM guests must process every
page assigned to a guest. For larger guests, this can tie up a vcpu
for a significant amount of time, as the operations are not
preemptible.
For guests using Hardware Assisted Paging (HAP, see below) this is
CVE-2014-5146. For guests not using HAP this is CVE-2014-5149.
IMPACT
=====
A malicious HVM guest with a large allocation of shadow/p2m RAM
can mount a denial of service attack affecting the whole system.
VULNERABLE SYSTEMS
=================
ARM systems are not vulnerable.
All x86 Xen versions are vulnerable.
The vulnerability is only exposed to HVM guests.
In the default configuration, the vulnerability is only exposed to
large guests (guests assigned more than 128Gbytes of memory).
MITIGATION
=========
Running only PV guests, or only smaller guests will avoid this
problem.
Since the vulnerability actually depends on the guest's shadow memory,
if you are overriding the default allocation (which is about 0.5% of
guest RAM) by using the "shadow_memory=" VM configuration file option,
you should adjust your idea of a 'smaller' guest accordingly.
CREDITS
======
This issue was discovered by Jan Beulich.
RESOLUTION
=========
For HAP-enabled guests, the attached patch resolves ths issue.
HAP (Hardware Assisted Paging, aka nested paging) is enabled by
default if the system is suitably capable. The VM configuration file
can disable or enable HAP explicitly by setting "hap=0" or
"hap=1".
HAP can also be globally disabled by specifying "hap=off" on the
hypervisor command line.
There is no resolution for guests using shadow pagetables (i.e., not
using HAP) at this time.
xsa97-hap-unstable.patch xen-unstable
xsa97-hap-4.4.patch Xen 4.4.x
xsa97-hap-4.3.patch Xen 4.3.x
xsa97-hap-4.2-prereq.patch, xsa97-hap-4.2.patch Xen 4.2.x
$ sha256sum xsa97*.patch
c9e0e9f136db1b976ea371be10430598a7f21b4a33b4849f2081566657ff5da1
xsa97-hap-4.2.patch
c525a99263eed6f93fad685ae9dad1ae10c8930345ec52659211541640797bb5
xsa97-hap-4.2-prereq.patch
cfab6521221a5058a0dfbb6d59c3c4cd0e7f4239bb6cbee2723de22c33caafda
xsa97-hap-4.3.patch
138511f2fd8362366e09dda18443387886ec4397eecc1a2f6a7e85643bd415e8
xsa97-hap-4.4.patch
58c56daa01f20be0317700d383dfbba8de35695bd38a9860c0c0463181d76351
xsa97-hap-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJT6hBmAAoJEIP+FMlX6CvZ8sgIAIqtUEu6CS5+H3enavmmLhuh
PGLCqQOBVWn99+m6bMqk+WvZOkW9CLxiX6+78XsheJlmUFBtHc3rG53wR0voo6Vr
BXyU3XY2n4aEh1klstS3gq/J37L86fEi2a+MaAePbPZ4qdWvFh3zDhRrLTQ/TDvK
0tfze9fF6K24Ab7jAcstF2gn+NhrrS3L3pvvgD/P5T1LR8HrEsyyhTlf7c34T5cp
RnSM19CUqAVAJeyN6WI2meZ3C+nvxLiNRUEQQikf4yCKqGxevzjBLAbXlcw4ELnF
9rG7Yd1aRJh4pQkViFDIdB3x8Xb9HuT7kFsQ7kBZc3an9JkbxxTGQd82XjODM1Q=A/Ph
-----END PGP SIGNATURE-----
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users