WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-changelog

[Xen-changelog] [xen-3.4-testing] x86, shadow: Fix read-to-use race cond

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-3.4-testing] x86, shadow: Fix read-to-use race condition
From: "Xen patchbot-3.4-testing" <patchbot-3.4-testing@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 13 Apr 2010 09:10:18 -0700
Delivery-date: Tue, 13 Apr 2010 09:10:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1271092406 -3600
# Node ID ee86b32ed87971ba381ce4e112d88e4796c62056
# Parent  762732d70aebf0fec10e4e55b68aa8254c1784fa
x86, shadow: Fix read-to-use race condition

If OOS mode is enabled, after last possible resync, read the guest l1e
one last time.  If it's different than the original read, start over
again.

This fixes a race which can result in inconsistent in-sync shadow
tables, leading to corruption:

v1: take page fault, read gl1e from an out-of-sync PT.
v2: modify gl1e, lowering permissions
[v1,v3]: resync l1 which was just read.
v1: propagate change to l1 shadow using stale gl1e

Now we have an in-sync shadow with more permissions than the guest.

The resync can happen either as a result of a 3rd vcpu doing a cr3
update, or under certain conditions by v1 itself.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
xen-unstable changeset:   21150:78488a63bbc2
xen-unstable date:        Mon Apr 12 17:51:56 2010 +0100
---
 xen/arch/x86/mm/shadow/multi.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+)

diff -r 762732d70aeb -r ee86b32ed879 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c    Mon Apr 12 18:13:13 2010 +0100
+++ b/xen/arch/x86/mm/shadow/multi.c    Mon Apr 12 18:13:26 2010 +0100
@@ -239,6 +239,23 @@ shadow_check_gwalk(struct vcpu *v, unsig
 
     return !mismatch;
 }
+
+static int
+shadow_check_gl1e(struct vcpu *v, walk_t *gw)
+{
+    guest_l1e_t *l1p, nl1e;
+
+    if ( !mfn_valid(gw->l1mfn) )
+        return 0;
+
+    /* Can't just pull-through because mfn may have changed */
+    l1p = map_domain_page(mfn_x(gw->l1mfn));
+    nl1e.l1 = l1p[guest_l1_table_offset(gw->va)].l1;
+    unmap_domain_page(l1p);
+
+    return gw->l1e.l1 != nl1e.l1;
+}
+
 
 /* Remove write access permissions from a gwalk_t in a batch, and
  * return OR-ed result for TLB flush hint and need to rewalk the guest
@@ -3209,6 +3226,15 @@ static int sh_page_fault(struct vcpu *v,
          * OOS but not in the hash table anymore. */
         shadow_unlock(d);
         return 0;
+    }
+
+    /* Final check: if someone has synced a page, it's possible that
+     * our l1e is stale.  Compare the entries, and rewalk if necessary. */
+    if ( shadow_check_gl1e(v, &gw)  )
+    {
+        perfc_incr(shadow_inconsistent_gwalk);
+        shadow_unlock(d);
+        goto rewalk;
     }
 #endif /* OOS */
 

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-3.4-testing] x86, shadow: Fix read-to-use race condition, Xen patchbot-3.4-testing <=