DOMID_XEN and iomem_access_permitted

DOMID_XEN and iomem_access_permitted

[George Dunlap]

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

Re: DOMID_XEN and iomem_access_permitted

[Keir Fraser]

On 12/05/2010 21:45, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> 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().

Yes, I'll patch it this way, thanks.

> 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.

Unprivileged domains will be unable to obtain a reference to dom_xen. So
this bug can only trigger from dom0.

 -- Keir

Re: DOMID_XEN and iomem_access_permitted

[George Dunlap]

Keir Fraser wrote:
> Unprivileged domains will be unable to obtain a reference to dom_xen. So
> this bug can only trigger from dom0.
>   
OK -- and DOMID_IO redirects the checks back to current->domain before 
calling iomem_access_permitted() in get_page_from_l1e().  So we don't 
believe a domU should be able to pass a "dummy domain" to 
iomem_access_permitted().  Good to know. :-)

 -George

Re: DOMID_XEN and iomem_access_permitted

[Keir Fraser]

On 12/05/2010 21:45, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> 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().

Fixed as xen-unstable:21373, and I will also backport for 4.0.1 and 3.4.3.

 -- Keir