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

[Xen-devel] DOMID_XEN and iomem_access_permitted

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Wed, 12 May 2010 15:45:41 -0500
  • Cc:
  • Delivery-date: Wed, 12 May 2010 13:56:06 -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=SNcQpqh1+ZwnWQIbbS2q3I8/g3zBktTpBLXUZgH9ATrhAL95R4wEnVdiNU5ZRyUGgD seAvIUsQjOIaqbAOTffI8UpfOMJjL+hhb9lYuEcZwegNmhLqm8Ame6hexucl09FT1Rca uKs5z4e52g6czT0cpNuy5x3n10zvQwDAGn/cQ=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

So I was looking a bit more into the xentrace t_info size bug. Xen and
xentrace having a different idea what t_info_size meant was the root
cause, but that actually tickled another bug,

If you pass DOMID_XEN into do_mmu_update with a "garbage" mfn, the mfn
will eventually filter down to xen/arch/x86/mm.c:get_page_from_l1e().
Since the mfn is invalid, it will attempt to interpret the mfn as an
MMIO range, and call iomem_access_permitted() to see if mapping this
mfn is allowed.  However, the "xen" domain (which is what you get if
you pass DOMID_XEN) has a null iomem_caps pointer.  So when
iomem_access_permitted() passes the iomem_caps pointer to
rangest_contains_range(), it dereferences NULL and crashes Xen.

Two questions, first regarding the "right" solution.
iomem_access_permitted() is called in two other places: gnttab.c and
1) Is it the case that every other domain (except the idle domain) is
guaranteed to have a valid iomem_caps?
2) Is it possible to get the "xen" domain at the caller in gnttab.c
and shadow/multi.c?

If the answers are "yes" and "no" respectively, we should probably
just add a check to get_page_from_l1e() to check if d->domain_id is
DOMID_XEN before attempting to interpret the mfn as mmio.

Any other combination of answers, we should probably change
iomem_access_permitted() to check d->iomem_caps, and return 0 if it's

Actually, setting up an empty rangeset for the "xen" domain might be
the best solution... it works no matter what the answers above are,
and has fewer special cases in the code.  Looks like it would mainly
involve actually initializing the rangeset code even for dummy domains
in domian_create().

Second question: Is it possible for a domU to crash the host with this
bug?  It looks like set_foreigndom() will only allow you to use
DOMID_XEN from domain 0.  If the answer to question 1 above is "yes",
then I think we can safely say domU can't exploit this bug to cause a
denial-of-service attack.



Xen-devel mailing list



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