All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [PATCH] xen/p2m: check MFN is in range before using the m2p table
Date: Thu, 29 Aug 2013 11:31:21 +0100	[thread overview]
Message-ID: <521F22F9.6040004@citrix.com> (raw)
In-Reply-To: <521F0F5602000078000EF4CA@nat28.tlf.novell.com>

On 29/08/13 08:07, Jan Beulich wrote:
>>>> On 28.08.13 at 19:30, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> On hosts with more than 168 GB of memory, a 32-bit guest may attempt
>> to grant map an MFN that is not cannot lookup in its mapping of the
>> m2p table.  There is an m2p lookup as part of m2p_add_override() and
>> m2p_remove_override().  The lookup falls off the end of the mapped
>> portion of the m2p and (because the mapping is at the highest virtual
>> address) wraps around and the lookup causes a fault on what appears to
>> be a user space address.
>>
>> do_page_fault() (thinking it's a fault to a userspace address), tries
>> to lock mm->mmap_sem.  If the gntdev device is used for the grant map,
>> m2p_add_override() is called from from gnttab_mmap() with mm->mmap_sem
>> already locked.  do_page_fault() then deadlocks.
>>
>> The deadlock would most commonly occur when a 64-bit guest is started
>> and xenconsoled attempts to grant map its console ring.
>>
>> Introduce mfn_to_pfn_no_overrides() which checks the MFN is within the
>> mapped portion of the m2p table before accessing the table and use
>> this in m2p_add_override(), m2p_remove_override(), and mfn_to_pfn()
>> (which already had the correct range check).
>>
>> All faults caused by accessing the non-existant parts of the m2p are
>> thus within the kernel address space and exception_fixup() is called
>> without trying to lock mm->mmap_sem.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> This all looks quite fine to me, but iiuc it only removes the deadlock,
> it doesn't make things work. In order to make it work I think we'd
> need a hypercall (albeit even then it would work only up to 1Tb).
> Otoh the question of course is whether driving this big a system
> with a 32-bit Dom0 kernel is a reasonable thing in the first place.

It should be sufficient as either an MFN is owned by this domain and
thus it is within the m2p mapping or it's a foreign MFN and it will be
looked up via the m2p overrides.

However, I note I got one of the tests wrong in mfn_to_pfn() and it's
broken.  It should be:

	pfn = mfn_to_pfn_no_overrides(mfn);
	if (pfn == ~0 || get_phys_to_machine(pfn) != mfn)
		pfn = m2p_find_override_pfn(mfn, ~0);

Or the equivalent (because get_phys_to_machine(~0) returns
INVALID_P2M_ENTRY which is != mfn:

	pfn = mfn_to_pfn_no_overrides(mfn);
	if (get_phys_to_machine(pfn) != mfn)
		pfn = m2p_find_override_pfn(mfn, ~0);

David

      reply	other threads:[~2013-08-29 10:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 17:30 [PATCH] xen/p2m: check MFN is in range before using the m2p table David Vrabel
2013-08-29  7:07 ` Jan Beulich
2013-08-29 10:31   ` David Vrabel [this message]

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=521F22F9.6040004@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=stefano.stabellini@citrix.com \
    --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.