Re: [Xen-devel] XSA-60 solutions

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Sep 30, 2013 at 08:28:53PM +0000, Liu, Jinsong wrote:
> Hi, All
> 
> This email provides 2 solutions for XSA-60 issue found by Konrad (refer 
> attached email for XSA-60 please).

It is actually by Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx> (CC-ed here).
> 
> 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

> Date: Wed, 24 Jul 2013 11:36:55 +0000
> From: "Xen.org security team" <security@xxxxxxx>
> To: "xen-announce@xxxxxxxxxxxxx" <xen-announce@xxxxxxxxxxxxx>,
>  "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>,
>  "xen-users@xxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxx>,
>  "oss-security@xxxxxxxxxxxxxxxxxx" <oss-security@xxxxxxxxxxxxxxxxxx>
> CC: "Xen.org security team" <security@xxxxxxx>
> Subject: [Xen-devel] Xen Security Advisory 60 (CVE-2013-2212) - Excessive
>  time to disable caching with HVM guests with PCI passthrough
> 
> -----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-----

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel