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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: xen crash in tmem: checking a xen pfn for domain ownership
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 17 Sep 2010 09:48:38 -0700 (PDT)
Cc: Xen-devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 17 Sep 2010 09:51:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8B95748.23679%keir.fraser@xxxxxxxxxxxxx>
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>
References: <5638cf67-e92c-45b3-8806-a0baba1eb8aa@default C8B95748.23679%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


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