tracking of Xen heap pages shared with guest

tracking of Xen heap pages shared with guest

[Jan Beulich]

I assume I'm overlooking something, but can someone explain how page
tracking works in the following two cases:

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.

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

Apparently I'm just failing to find the places where extra reference
counts are being established for such pages...

Thanks, Jan

Re: tracking of Xen heap pages shared with guest

[Keir Fraser]

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.

> 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

Re: tracking of Xen heap pages shared with guest

[Jan Beulich]

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

Re: tracking of Xen heap pages shared with guest

[Keir Fraser]

On 14/3/08 13:41, "Jan Beulich" <jbeulich@novell.com> wrote:

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

It cannot be freed by the guest. Note that free_domheap_pages() is a no-op
for Xen-heap pages.

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

Point out the specific lines of code that you think are offending and I'll
take a look.

 -- Keir

Re: tracking of Xen heap pages shared with guest

[Jan Beulich]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 14.03.08 14:48 >>>
>On 14/3/08 13:41, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> 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.
>
>It cannot be freed by the guest. Note that free_domheap_pages() is a no-op
>for Xen-heap pages.

Ah, right. I keep getting confused by this special treatment of the Xen
heap.

>>> 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.
>
>Point out the specific lines of code that you think are offending and I'll
>take a look.

Your above comment clarifies matters here, too - since
free_domheap_pages() only removes Xen heap pages from the owning
domain's list, they cannot get assigned for other purposes (and they
would simply get re-added to the list the next time they'd get passed
to share_xen_pages_with_guest()).

Thanks and sorry for the noise, Jan

Re: tracking of Xen heap pages shared with guest

[Keir Fraser]

On 14/3/08 14:07, "Jan Beulich" <jbeulich@novell.com> wrote:

>> It cannot be freed by the guest. Note that free_domheap_pages() is a no-op
>> for Xen-heap pages.
> 
> Ah, right. I keep getting confused by this special treatment of the Xen
> heap.

At some point I'll get round to killing off the Xen heap, and replace this
particular feature of it with a better-named page flag.

 -- Keir