From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: Wei.Liu2@citrix.com, Tim Deegan <tim@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
stefano.stabellini@citrix.com, Jan Beulich <jbeulich@suse.com>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH for-4.6] xen/mm: populate_physmap: validate correctly the gfn for direct mapped domain
Date: Thu, 13 Aug 2015 10:33:46 +0100 [thread overview]
Message-ID: <1439458426.23981.37.camel@citrix.com> (raw)
In-Reply-To: <1439314888-24813-1-git-send-email-julien.grall@citrix.com>
On Tue, 2015-08-11 at 18:41 +0100, Julien Grall wrote:
> Direct mapped domain has already the memory allocated 1:1, so we are
> directly using the gfn as mfn to map the RAM in the guest.
>
> While we are validating that the page associated to the first mfn belongs
> to
> the domain, the subsequent MFN are not validated when the extent_order
> is > 0.
>
> This may result to map memory region (MMIO, RAM) which doesn't belong to
> the
> domain.
>
> Although, only DOM0 on ARM is using a direct memory mapped. So it
> doesn't affect any guest (at least on the upstream version) or even x86.
>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
>
> ---
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
>
> This patch is a candidate for Xen 4.6 and backport to Xen 4.5 (and
> maybe 4.4).
>
> The hypercall is used for the ballooning code and only DOM0 on ARM
> is a direct mapped domain.
>
> The current code to validate the GFN passed by the populate physmap
> hypercall has been moved in a for loop in order to validate each
> GFN when the extent order is > 0.
>
> Without it, direct mapping domain may be able to map memory region
> which doesn't belong to it.
>
> I think the switch to the for loop is pretty safe and contained. The
> worst thing that could happen is denying mapping more often than we
> use to do. Although, IIRC Linux is mostly mapping page one by one
> (i.e extent order = 0).
> ---
> xen/common/memory.c | 30 ++++++++++++++++++------------
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 61bb94c..7cc8af4 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -126,22 +126,28 @@ static void populate_physmap(struct memop_args *a)
> if ( is_domain_direct_mapped(d) )
> {
> mfn = gpfn;
> - if ( !mfn_valid(mfn) )
> +
> + for ( j = 0; j < (1 << a->extent_order); j++, mfn++ )
> {
> - gdprintk(XENLOG_INFO, "Invalid mfn
> %#"PRI_xen_pfn"\n",
> + if ( !mfn_valid(mfn) )
> + {
> + gdprintk(XENLOG_INFO, "Invalid mfn
> %#"PRI_xen_pfn"\n",
> mfn);
> - goto out;
> + goto out;
> + }
> +
> + page = mfn_to_page(mfn);
> + if ( !get_page(page, d) )
> + {
> + gdprintk(XENLOG_INFO,
> + "mfn %#"PRI_xen_pfn" doesn't belong to
> the"
> + " domain\n", mfn);
> + goto out;
This will leak the references on any earlier pages, which will happen all
the time if you are cross a boundary from RAM into e.g. MMIO or whatever.
A variant of get_page which took an order argument and returned either with
0 or 1<<order refs taken would perhaps make this easier to deal with. I
suppose we don't already have one of those, but you could add it.
Oh, am I wrong and we do get_page then immediately put_page for every page?
I suppose that is one way to check the current owner, but I think it needs
a comment at least (it did before TBH, just iterating over many pages makes
it seem even odder).
Is that really the best way to ask if a page is owned by a given domain tho
ugh? Does page_get_owner not suffice?
> + }
> + put_page(page);
> }
>
> - page = mfn_to_page(mfn);
> - if ( !get_page(page, d) )
> - {
> - gdprintk(XENLOG_INFO,
> - "mfn %#"PRI_xen_pfn" doesn't belong to the"
> - " domain\n", mfn);
> - goto out;
> - }
> - put_page(page);
> + page = mfn_to_page(gpfn);
> }
> else
> page = alloc_domheap_pages(d, a->extent_order, a
> ->memflags);
next prev parent reply other threads:[~2015-08-13 9:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 17:41 [PATCH for-4.6] xen/mm: populate_physmap: validate correctly the gfn for direct mapped domain Julien Grall
2015-08-12 9:16 ` Jan Beulich
2015-08-12 9:25 ` Julien Grall
2015-08-12 9:19 ` Wei Liu
2015-08-12 9:28 ` Wei Liu
2015-08-13 9:33 ` Ian Campbell [this message]
2015-08-13 9:54 ` Jan Beulich
2015-08-13 10:14 ` Ian Campbell
2015-08-13 10:29 ` Jan Beulich
2015-08-13 10:41 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1439458426.23981.37.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Wei.Liu2@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=julien.grall@citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.