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@lists.xensource.com
http://lists.xensource.com/xen-devel