This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: xen crash in tmem: checking a xen pfn for domain ownersh

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: xen crash in tmem: checking a xen pfn for domain ownership
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 17 Sep 2010 18:25:53 +0100
Cc: Xen-devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 17 Sep 2010 10:26:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <425889fe-2961-445b-9581-55fba21bb89a@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActWiGJD+HwqHI6KQ3GZi8SjLwX8QQABP7dd
Thread-topic: xen crash in tmem: checking a xen pfn for domain ownership
User-agent: Microsoft-Entourage/
Gfn_to_mfn() takes a domain as a parameter. It looks up gfn in that domain's
p2m. The only RAM-typed pfns that can be present in a domain's p2m, if it is
not sharing pages via memshr, are the domain's own pages. As far as I know,
at least. It does no harm for you to switch to gfn_to_mfn_unshare(), but I
doubt this is the fix for your current problem.

 -- Keir

On 17/09/2010 17:48, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> Thanks for the reply, but I'm not sure I understand.
> Ignore memory sharing for now...
> Are you saying, yes, the ownership check IS performed?
> E.g. if gpfn is a random number, NULL will always be
> returned (unless of course the random number happens
> to be a valid gfn for current->domain)?
> Or are you saying its plausible that this IS the problem
> (that I am not checking for ownership)?
> Now bring memory sharing back in...
> Since tmem and memory sharing are supposed to be complementary
> (though I don't think anybody has ever tried using both
> together), are you saying I should change this one
> call from gfn_to_mfn() to gfn_to_mfn_unshare() for
> some reason (e.g. maybe to avoid a race)?  Note
> that this code is just getting a virtual address
> to copy a page to/from the guest.
> Thanks,
> Dan
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Friday, September 17, 2010 10:35 AM
>> To: Dan Magenheimer; Jan Beulich
>> Cc: Xen-devel
>> Subject: Re: xen crash in tmem: checking a xen pfn for domain ownership
>> If you could be doing memory sharing then you might need to use
>> gfn_to_mfn_unshare()? Otherwise it looks pretty plausible, and that one
>> flaw
>> is pretty minor as you're probably not using memshr.
>>  -- Keir
>> On 17/09/2010 17:29, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
>> wrote:
>>> Does the construct:
>>>   xen_pfn_t gpfn;
>>>   p2m_type_t t;
>>>   unsigned long mfn;
>>>   mfn = mfn_x(gfn_to_mfn(current->domain, gpfn, &t));
>>>   if (t != p2m_ram_rw || cli_mfn == INVALID_MFN)
>>>       return NULL; /* bad */
>>>   return map_domain_page(mfn)
>>> somehow check to ensure that pfn belongs to current->domain?
>>> (See cli_mfn_to_va() in common/tmem_xen.c.)
>>> If not, is there an easy way to perform that check?
>>> (preferably one that works for both HVM and PV guests)
>>> In debugging a tmem Linux-side guest patch, I discovered
>>> that a bad mfn passed by the guest can crash Xen and
>>> I think this assumption might be the problem.
>>> Thanks,
>>> Dan

Xen-devel mailing list