[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] DOMID_XEN and iomem_access_permitted
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 shadow/multi.c. 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 NULL. 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. Thoughts? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |