[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] Fix read-to-use race condition in shadow code


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Mon, 12 Apr 2010 17:05:12 +0100
  • Delivery-date: Mon, 12 Apr 2010 09:11:28 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=U52E/EzCyWom4iQn+nAY3BUZ2jfKUF2zWEvEA1Z1bKmJeMme4mlponZepNAFeNdqPN MWNEq+80KtnO9PSTinpl1x8YHYh1fZvX9okQi06rmfbYey8W9M1RWqfVAuPkpPU3KvBS pNXWRsaMg6kHtFoX896srecvRADWT1XZpgYQI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.

This should probably be back-ported to 3.4.x and 4.0.x.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

Attachment: 20100412-unstable-fix-gw-to-propagate-race.diff
Description: Text Data

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.