[RFC PATCH] xen/arm: try to get stack in any case

[RFC PATCH] xen/arm: try to get stack in any case

[Frediano Ziglio]

Well,
  this is more an experiment than a patch but in my case was really
useful. Basically I was trying to get dom0 raw stack hitting '0' key
on Xen console. The problem is that when you hit such key you are Xen
domain, not domain 0 (code is called from Xen console). While Xen is
handling '0' command (dump dom0 state) show_guest_stack (in
xen/arch/arm/traps.c) try to get page from stack pointer failing as is
not current domain. In my case I had only domain0 so EL1 TTBR0/TTBR1
was domain0 and this patch work but obviously this can lead on real
cases to dump pages not from the wanted domain.

Possible solution is to get manually TTBR0/TTBR1 from the proper
domain and manually parse page tables. Now some question
- did somebody else have same issue?
- is there any helper function to get the proper page?

Regards,
   Frediano


---
 xen/arch/arm/mm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 46b6d98..c76c811 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1195,11 +1195,10 @@ int get_page(struct page_info *page, struct
domain *domain)
 {
     struct domain *owner = page_get_owner_and_reference(page);

-    if ( likely(owner == domain) )
+    if ( likely(owner == domain) || owner != NULL )
         return 1;

-    if ( owner != NULL )
-        put_page(page);
+    put_page(page);

     return 0;
 }
-- 
1.9.1

Re: [RFC PATCH] xen/arm: try to get stack in any case

[Julien Grall]

Hi Frediano,

On 10/17/2014 04:22 PM, Frediano Ziglio wrote:
> Well,
>   this is more an experiment than a patch but in my case was really
> useful. Basically I was trying to get dom0 raw stack hitting '0' key
> on Xen console. The problem is that when you hit such key you are Xen
> domain, not domain 0 (code is called from Xen console). While Xen is
> handling '0' command (dump dom0 state) show_guest_stack (in
> xen/arch/arm/traps.c) try to get page from stack pointer failing as is
> not current domain. In my case I had only domain0 so EL1 TTBR0/TTBR1
> was domain0 and this patch work but obviously this can lead on real
> cases to dump pages not from the wanted domain.

I guess you see "Failed to convert stack to physical address"?

> Possible solution is to get manually TTBR0/TTBR1 from the proper
> domain and manually parse page tables. Now some question
> - did somebody else have same issue?
> - is there any helper function to get the proper page?

The function get_page is used in many different place to get a reference
to the page and check if the page belongs to the domain.

This patch would lead to a security issue on most of the hypercalls that
deal with memory.

The proper solution would be to switch temporally on the p2m of the v we
want to dump (see an example with flush_tlb_domain());

Regards,

-- 
Julien Grall

Re: [RFC PATCH] xen/arm: try to get stack in any case

[Ian Campbell]

On Fri, 2014-10-17 at 16:46 +0100, Julien Grall wrote:
> The proper solution would be to switch temporally on the p2m of the v we
> want to dump (see an example with flush_tlb_domain());

Yes, certainly the proper fix would be either in get_page_from_gva or in
the caller, certainly not as far down the stack as get_page.

Ian.

Re: [RFC PATCH] xen/arm: try to get stack in any case

[Frediano Ziglio]

2014-10-20 9:30 GMT+01:00 Ian Campbell <Ian.Campbell@citrix.com>:
> On Fri, 2014-10-17 at 16:46 +0100, Julien Grall wrote:
>> The proper solution would be to switch temporally on the p2m of the v we
>> want to dump (see an example with flush_tlb_domain());
>
> Yes, certainly the proper fix would be either in get_page_from_gva or in
> the caller, certainly not as far down the stack as get_page.
>
> Ian.
>

Thanks you guys, I'll try to write and test a proper patch.

Frediano