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/
Home Products Support Community News


[Xen-devel] DOMID_XEN and iomem_access_permitted

To: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] DOMID_XEN and iomem_access_permitted
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 12 May 2010 15:45:41 -0500
Delivery-date: Wed, 12 May 2010 13:56:06 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=mG135NHvFvidRvm1JYRsvSPb4tEVWOtahR5AsX09lhI=; b=wm78gsbsDSYPCyfLJgYhKRalTlJLAk44ZBctcprhpn768oZkEHz2nneSPq55ndRf4J e34YXJbGQf5WKLwjCdfIiBWKkrG6m9lF9yMO/xXb2PSyEPGPCwMfl+ZcYzleeqsD8DhP 3XroPsw3el7oGCv2LHMP2Ow3hrNCdyikp52k4=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>