All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>, xen-devel@lists.xensource.com
Cc: joserenato.santos@hp.com
Subject: Re: tracking of Xen heap pages shared with guest
Date: Fri, 14 Mar 2008 13:41:07 +0000	[thread overview]
Message-ID: <47DA8E83.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C40029B4.15026%keir.fraser@eu.citrix.com>

>>> Keir Fraser <keir.fraser@eu.citrix.com> 14.03.08 14:10 >>>
>On 14/3/08 12:59, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> a) A guest unintentionally or maliciously frees (e.g. through
>> decrease_reservation) a page shared from the Xen heap (e.g. the
>> shared info page). From what I can see, such a page would have a
>> reference count of 1 (from share_xen_page_with_guest(), assuming
>> the guest doesn't have the page mapped), and would hence be
>> immediately freed with the corresponding put_page(). Nevertheless
>> Xen itself may continue to write to such a page.
>
>There is no extra reference count in this case. Xen's own reference is
>implicit, and this is okay because such pages are explicitly freed during
>domain final destruction, and at that point Xen knows the pages are going
>away.

Right, but the question was - what if the guest erroneously or
maliciously frees the page? If there's indeed no extra reference, then
the page (which Xen will continue to write to) may get assigned to a
different domain, including dom0, and hence the whole system could
get at risk.

>> b) A domU that had a xenoprof buffer allocated gets killed. Since the
>> xenoprof code directly calls free_xenheap_pages() on the buffer,
>> any mapping dom0 may have to it would not be considered, and hence
>> dom0 would retain a mapping to free memory. Additionally, the
>> put_page() in unshare_xenoprof_page_with_guest() could revert the
>> singe reference to the page established through
>> share_xen_page_with_guest() (i.e. if dom0 never mapped or already
>> unmapped the buffer), which again would result in the buffer getting
>> freed (and thus d->xenoprof->rawbuf becoming stale).
>
>I'm no expert on xenoprof. I've cc'ed Renato.
>
>Wouldn't dom0 mappings bump the page reference count, and this would prevent
>the domU being destroyed (remember that non-empty domain page ownership
>lists hold a domain reference)?

As I understand it, the pages get shared with dom0, so ownership also
transfers to dom0, which doesn't prevent the guest from being fully
destroyed.

Jan

  reply	other threads:[~2008-03-14 13:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-14 12:59 tracking of Xen heap pages shared with guest Jan Beulich
2008-03-14 13:10 ` Keir Fraser
2008-03-14 13:41   ` Jan Beulich [this message]
2008-03-14 13:48     ` Keir Fraser
2008-03-14 14:07       ` Jan Beulich
2008-03-14 15:35         ` Keir Fraser

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=47DA8E83.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=joserenato.santos@hp.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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.