[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] tracking of Xen heap pages shared with guest



On 14/3/08 12:59, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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.

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

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.