[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] XSA-60 solutions
- To: Jan Beulich <JBeulich@xxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
- From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
- Date: Mon, 30 Sep 2013 20:28:53 +0000
- Accept-language: en-US
- Cc: "Auld, Will" <will.auld@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>, "suravee.suthikulpanit@xxxxxxx" <suravee.suthikulpanit@xxxxxxx>, "sherry.hurwitz@xxxxxxx" <sherry.hurwitz@xxxxxxx>
- Delivery-date: Mon, 30 Sep 2013 20:29:39 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
- Thread-index: Ac6+G61iULkUAOZTS4WGR8o9roAbtw==
- Thread-topic: XSA-60 solutions
Hi, All
This email provides 2 solutions for XSA-60 issue found by Konrad (refer
attached email for XSA-60 please).
Basically it involves how to emulate guest setting cr0.cd. For shadow, as Jan
pointed out in earlier email Xen drop all shadows so that any new ones would be
created with UC memory type, _not_ involving iteration over the whole address
space. For EPT, currently Xen traverse all ept entries via problematic
set_uc_mode, resulting in DOS-like behavior, so this email focus on Intel EPT
case.
Solution 1 is Dual-EPT tables: When guest setting cr0.cd trapped, stop using
normal EPT, switch to a temp EPT table and populate new EPT entries w/ UC type
on demand at later EPT violation. When guest clearing cr0.cd, switch back to
normal EPT. In this way, _no_ unbounded loop involved and hence security hole
avoided.
Some concerns for Dual-EPT: the 1st concern comes from cachablity confliction
between guest and Xen memory type point of view, though it also exists in
current implementation. The 2nd concern comes from Dual EPT tables
inconsistency/sync issue: things become complicated when p2m modifying, PoD
populating, and super page spliting, etc.
Solution 2 is via PAT emulation: For guest w/o VT-d, and for guest with VT-d
but snooped, Xen need do nothing, just simply ignore guest setting cr0.cd,
since hardware snoop mechanism has ensured cache coherency (under these cases
currently Xen has set EPT iPAT bit, ignore guest's memory type opinion); For
guest with VT-d but non-snooped, cache coherency can not be guaranteed by h/w
snoop so guest's memory type opinion must be considered (under this case Xen
set iPAT bit combining guest and host memory type opinion). Only under this
case PAT emulation need set all IA32_PAT fields as UC so that guest memory type
are all UC.
Concern for PAT solution still comes from cachablity confliction between guest
and Xen.
Thoughts?
BTW, today is Chinese National day, I will have several days travel with no
email access, but your comments/suggestions are highly appreciated and I will
reply ASAP after I come back.
Thanks,
Jinsong --- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2013-2212 / XSA-60
version 4
Excessive time to disable caching with HVM guests with PCI passthrough
UPDATES IN VERSION 4
====================
Public release.
ISSUE DESCRIPTION
=================
HVM guests are able to manipulate their physical address space such that
processing a subsequent request by that guest to disable caches takes an
extended amount of time changing the cachability of the memory pages assigned
to this guest. This applies only when the guest has been granted access to
some memory mapped I/O region (typically by way of assigning a passthrough
PCI device).
This can cause the CPU which processes the request to become unavailable,
possibly causing the hypervisor or a guest kernel (including the domain 0 one)
to halt itself ("panic").
For reference, as long as no patch implementing an approved alternative
solution is available (there's only a draft violating certain requirements
set by Intel's documentation), the problematic code is the function
vmx_set_uc_mode() (in that it calls ept_change_entry_emt_with_range() with
the full guest GFN range, which the guest has control over, but which also
would be a problem with sufficiently large but not malicious guests).
IMPACT
======
A malicious domain, given access to a device with memory mapped I/O
regions, can cause the host to become unresponsive for a period of
time, potentially leading to a DoS affecting the whole system.
VULNERABLE SYSTEMS
==================
Xen version 3.3 onwards is vulnerable.
Only systems using the Intel variant of Hardware Assisted Paging (aka EPT) are
vulnerable.
MITIGATION
==========
This issue can be avoided by not assigning PCI devices to untrusted guests, or
by running HVM guests with shadow mode paging (through adding "hap=0" to the
domain configuration file).
CREDITS
=======
Konrad Wilk found the issue as a bug, which on examination by the
Xenproject.org Security Team turned out to be a security problem.
RESOLUTION
==========
There is currently no resolution to this issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJR77wrAAoJEIP+FMlX6CvZB5MH/ibfpjHuoGOIo7mWukld4NM5
UVIKC+rTrnkYhbF2f+xIM833+WAUjPuXZKZ6/EirDAPAAQCut2DouNvVdVnZ5cBx
rq0N8l9wy0/dq/7kCyI3kAGFlJ3VYz7aM5+TTPFGfO7Yq3ohUNu2EE4vv/t5KVjD
H4reh8UaA5QuRbdh3evCM9Vdt2syqi8JQwB5D2CJqrgAuFPwEVle8MLKSXWWb/+V
KUy+mRAb1tN3jbWIev0TZ7Hm3x61yO60/WFzsQzkmkd+qWvC5btkWDg05K5DHC+Q
yvFU3Y5u7J/ub00ZO4e9wjNDG5+ItQUK4xp8y5s65qx27P/eK9VLi8dvnHVMk04=
=HUbY
-----END PGP SIGNATURE-----
Attachment:
ATT00001.txt
Description: ATT00001.txt
--- End Message ---
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|