XSA-64

CVE-2013-4356

问题描述

http://xenbits.xen.org/xsa/advisory-64.html

Memory accessible by 64-bit PV guests under live migration

On some hardware, during live migration of 64-bit PV guests, some parts of the guest’s shadow pagetables are mistakenly filled in with hypervisor mappings. This causes Xen to crash when those mappings are later cleared. Before the crash, a malicious guest could use hypercalls to cause Xen to read and write the parts of memory pointed to by the stray mappings.

logic error (incorrect initialization)

Patch描述

http://xenbits.xen.org/xsa/xsa64.patch

x86/mm/shadow: Fix initialization of PV shadow L4 tables.

In the common case, all those slots are zero in the idle pagetable, and no harm is done. But if any slot above #271 is non-zero, Xen will crash when that slot is later cleared (it attempts to drop shadow-pagetable refcounts on its own L4 pagetables).

Fix by using the new ROOTPAGETABLEPVXENSLOTS when appropriate. Monitor pagetables need the full Xen mappings, so they keep using the old name (with its new semantics).

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1433,15 +1433,19 @@ void sh_install_xen_entries_in_l4(struct vcpu *v, mfn_t gl4mfn, mfn_t sl4mfn)
 {
     struct domain *d = v->domain;
     shadow_l4e_t *sl4e;
+    unsigned int slots;
 
     sl4e = sh_map_domain_page(sl4mfn);
     ASSERT(sl4e != NULL);
     ASSERT(sizeof (l4_pgentry_t) == sizeof (shadow_l4e_t));
     
     /* Copy the common Xen mappings from the idle domain */
+    slots = (shadow_mode_external(d)
+             ? ROOT_PAGETABLE_XEN_SLOTS
+             : ROOT_PAGETABLE_PV_XEN_SLOTS);
     memcpy(&sl4e[ROOT_PAGETABLE_FIRST_XEN_SLOT],
            &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT],
-           ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t));
+           slots * sizeof(l4_pgentry_t));
 
     /* Install the per-domain mappings for this domain */
     sl4e[shadow_l4_table_offset(PERDOMAIN_VIRT_START)]

Consequence

A malicious 64-bit PV guest, on a vulnerable host system, that can arrange for itself to be live-migrated, could read or write memory at high physical addresses on the host.

Note that once such a guest begins live migration the host is likely to eventually crash, either when the live migration completes or on an earlier page fault. This crash could be avoided if the malicious guest uses its improperly escalated privilege to prevent it.

DoS, information leak