Xen devel - May 2006 - [RESEND] Question about recursive mappings

[Previous one didn''t hit list after 3 days, trying a resend, sorry if 
both finally show up]

Hi,

are recursive mappings (ie: a page table entry pointing back to itself)
supported by Xen (on x86_64 at least)?
I''m asking cause i''m seeing many error logs from
get_page_type() telling
something like "saw L3_page_table expected L2_page_table" or "saw
L4_page_table expected L3_page_table" (finally leading to a failing 
mmu_update, i guess others happens on user pagetables switches).
Or maybe is there any workaround needed? (I think i saw something like
setting entry to 0 first then to the recursive entry somewhere, but
can''t remember where).
By the way, i''m using recursive mappings in kernel page directory
(which
seems ok) and i temporay make user page directory recursive when i map
a user PGD in kernel space (mapping user PGD to a L4 entry of kernel 
tables, then using kernel L4 slot and user PGD recursive entry to access 
user page tables).

[edit]
Done some little research about the problem. Seems like NetBSD use the 
same thing and works, but there is no x86_64 ports for now. I''m
starting
to think that may be a x86_64 issue, maybe because recursive mappings 
don''t lead to conflicting types with only 2 levels.
Xen interface states that a page can only be of one type (PGD, PT, LDT, 
GDT  and R/W). I don''t know why there is a need to distinguish page 
table levels, but i''m afraid this restriction will conflit with some
MMU
implementation on x86_64 like NetBSD and OpenBSD, and maybe others 
(FreeBSD on top of my mind, don''t know how much the pmap implementation
diverged).
[/edit]

Regards,

Mathieu


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

Done some investingations in the mm code of Xen, i think the problem is 
that linear page tables entries are checked only on level 4 entries.
In my case, my recursive entry is in a L3 table, already validated as 
another type, hence not "valid" for Xen.
Will authorizing L3 or L2 recursive mappings induce a security hole or 
vulnerability?
If not, I''ll try to make a patch to address this issue (any hint
welcome
:)).

Regards,
Mathieu

Mathieu Ropert wrote:
> [Previous one didn''t hit list after 3 days, trying a resend, sorry
if
> both finally show up]
>
> Hi,
>
> are recursive mappings (ie: a page table entry pointing back to itself)
> supported by Xen (on x86_64 at least)?
> I''m asking cause i''m seeing many error logs from
get_page_type() telling
> something like "saw L3_page_table expected L2_page_table" or
"saw
> L4_page_table expected L3_page_table" (finally leading to a failing 
> mmu_update, i guess others happens on user pagetables switches).
> Or maybe is there any workaround needed? (I think i saw something like
> setting entry to 0 first then to the recursive entry somewhere, but
> can''t remember where).
> By the way, i''m using recursive mappings in kernel page directory
(which
> seems ok) and i temporay make user page directory recursive when i map
> a user PGD in kernel space (mapping user PGD to a L4 entry of kernel 
> tables, then using kernel L4 slot and user PGD recursive entry to 
> access user page tables).
>
> [edit]
> Done some little research about the problem. Seems like NetBSD use the 
> same thing and works, but there is no x86_64 ports for now. I''m 
> starting to think that may be a x86_64 issue, maybe because recursive 
> mappings don''t lead to conflicting types with only 2 levels.
> Xen interface states that a page can only be of one type (PGD, PT, 
> LDT, GDT  and R/W). I don''t know why there is a need to
distinguish
> page table levels, but i''m afraid this restriction will conflit
with
> some MMU implementation on x86_64 like NetBSD and OpenBSD, and maybe 
> others (FreeBSD on top of my mind, don''t know how much the pmap 
> implementation diverged).
> [/edit]
>
> Regards,
>
> Mathieu
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

> Done some investingations in the mm code of Xen, i think the 
> problem is that linear page tables entries are checked only 
> on level 4 entries.
> In my case, my recursive entry is in a L3 table, already 
> validated as another type, hence not "valid" for Xen.
Can you explain the pagtable structure a little better please. Does the
L3 contain an entry point at itself (recursive), or at another L3
(foreign)?

I''ve never come across non-root pagetable linear mappings other than in
the crock that is PAE (3 level) where you have to use 4 entries in an L2
to point to all the L2s due to the limited address space.

What OS are you porting? Was it written for 3-level pagetables, with the
x86 4th level being added on as an afterthought, perhaps with only a
single L4 for the system and just one entry being used?
> Will authorizing L3 or L2 recursive mappings induce a 
> security hole or vulnerability?
> If not, I''ll try to make a patch to address this issue (any 
> hint welcome :)).
I''m sure it can be done safely, but you''d best wrap a damp
towel around
your head while thinking about how. I wouldn''t want to slow down the
common case...

Ian 
 
> Regards,
> Mathieu
> 
> Mathieu Ropert wrote:
> 
> > [Previous one didn''t hit list after 3 days, trying a 
> resend, sorry if 
> > both finally show up]
> >
> > Hi,
> >
> > are recursive mappings (ie: a page table entry pointing back to 
> > itself) supported by Xen (on x86_64 at least)?
> > I''m asking cause i''m seeing many error logs from
get_page_type()
> > telling something like "saw L3_page_table expected 
> L2_page_table" or 
> > "saw L4_page_table expected L3_page_table" (finally leading
to a
> > failing mmu_update, i guess others happens on user 
> pagetables switches).
> > Or maybe is there any workaround needed? (I think i saw 
> something like 
> > setting entry to 0 first then to the recursive entry somewhere, but 
> > can''t remember where).
> > By the way, i''m using recursive mappings in kernel page
directory
> > (which seems ok) and i temporay make user page directory recursive 
> > when i map a user PGD in kernel space (mapping user PGD to 
> a L4 entry 
> > of kernel tables, then using kernel L4 slot and user PGD recursive 
> > entry to access user page tables).
> >
> > [edit]
> > Done some little research about the problem. Seems like 
> NetBSD use the 
> > same thing and works, but there is no x86_64 ports for now.
I''m
> > starting to think that may be a x86_64 issue, maybe because 
> recursive 
> > mappings don''t lead to conflicting types with only 2 levels.
> > Xen interface states that a page can only be of one type (PGD, PT, 
> > LDT, GDT  and R/W). I don''t know why there is a need to
distinguish
> > page table levels, but i''m afraid this restriction will 
> conflit with 
> > some MMU implementation on x86_64 like NetBSD and OpenBSD, 
> and maybe 
> > others (FreeBSD on top of my mind, don''t know how much the
pmap
> > implementation diverged).
> > [/edit]
> >
> > Regards,
> >
> > Mathieu
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23 May 2006, at 10:41, Ian Pratt wrote:
> Can you explain the pagtable structure a little better please. Does the
> L3 contain an entry point at itself (recursive), or at another L3
> (foreign)?
>
> I''ve never come across non-root pagetable linear mappings other
than in
> the crock that is PAE (3 level) where you have to use 4 entries in an 
> L2
> to point to all the L2s due to the limited address space.
And that''s something we don''t currently support. A slightly
more
generic linear pagetable logic that would permit us to support linear 
pagetables on PAE would be a good thing.

  -- Keir


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

Keir Fraser wrote:
>
> On 23 May 2006, at 10:41, Ian Pratt wrote:
>
>> Can you explain the pagtable structure a little better please. Does the
>> L3 contain an entry point at itself (recursive), or at another L3
>> (foreign)?
>>
>> I''ve never come across non-root pagetable linear mappings
other than in
>> the crock that is PAE (3 level) where you have to use 4 entries in an
L2
>> to point to all the L2s due to the limited address space.
>
>
> And that''s something we don''t currently support. A
slightly more
> generic linear pagetable logic that would permit us to support linear 
> pagetables on PAE would be a good thing.
>
>  -- Keir
>
A bit more explanation:
- All my L4 tables (kernel and user) have one of their entries pointing 
on themselves.
- As I can''t use the same tables in kernel and user mode on x86_64, the
kernel table is always the same, and sometimes needs to map a user L4 to 
modify.
- In order to do that, i set an entry of the kernel L4 to the machine 
address of the wanted L4 user table. So my L4 user recursive entry is 
used as a L3 one in kernel tables.
- When i want to access a user table in kernel mode, i do 2 mmu updates:
1/ Set a L4 kernel table entry with the machine address of the L4 user 
table i want to change. This step currently works.
2/ Set the L4 user table recursive as valid (i clear the valid bit when 
i''m done with my changes, don''t want the user to be able to
read his
page tables). This is where Xen refuse to update the tables.

About the possible fix, won''t something like trying a 
get_linear_pagetable() at all level works? Will it cause too much overhead?
Generally speaking, is allowing a R/O mapping of another table the 
domain own (whichever level it is) safe? At first thought, i don''t see 
any way of exploiting it.

Regards,
Mathieu

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

> About the possible fix, won''t something like trying a
> get_linear_pagetable() at all level works? Will it cause too 
> much overhead?
> Generally speaking, is allowing a R/O mapping of another 
> table the domain own (whichever level it is) safe? At first 
> thought, i don''t see any way of exploiting it.
Yes, it''s safe, you just need to get the ''general''
ref count right,
which as I recall, depends on whether the page you''re mapping is in the
same page table, or a foreign page table. The va back pointer means that
there is a unique ''normal'' place in each pagetable where a
given page
can be mapped, so you can easily inspect (via xen''s linear mapping) to
see whether the page belongs to the current pagetable or not.

One thing we do have to watch out for is when we introduce super page
mappings, as you have to be careful about using linear page tables in
this context -- the x86 pagetable format doesn''t allow you to generate
a
trap if a linear mapping attempts to misuse a superpage. That''s not
your
worry right now :-) 

Ian

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

Ian Pratt wrote:
>>About the possible fix, won''t something like trying a
>>get_linear_pagetable() at all level works? Will it cause too 
>>much overhead?
>>Generally speaking, is allowing a R/O mapping of another 
>>table the domain own (whichever level it is) safe? At first 
>>thought, i don''t see any way of exploiting it.
>>    
>>
>
>Yes, it''s safe, you just need to get the
''general'' ref count right,
>which as I recall, depends on whether the page you''re mapping is in
the
>same page table, or a foreign page table. The va back pointer means that
>there is a unique ''normal'' place in each pagetable where a
given page
>can be mapped, so you can easily inspect (via xen''s linear mapping)
to
>see whether the page belongs to the current pagetable or not.
>
>One thing we do have to watch out for is when we introduce super page
>mappings, as you have to be careful about using linear page tables in
>this context -- the x86 pagetable format doesn''t allow you to
generate a
>trap if a linear mapping attempts to misuse a superpage. That''s not
your
>worry right now :-) 
>
>Ian
>  
>
Ok, i''ve done a little patch which seems to resolve the issue on my
test
setup. Basically, i''ve modified get_linear_pagetable(), added a level 
parameter and call it for each level but level 1.
I need to do a little more test before i post the patch. As tomorrow is 
a national day, it should be ready friday.

Mathieu

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

On 24 May 2006, at 21:12, Mathieu Ropert wrote:
> Ok, i''ve done a little patch which seems to resolve the issue on
my
> test setup. Basically, i''ve modified get_linear_pagetable(), added
a
> level parameter and call it for each level but level 1.
> I need to do a little more test before i post the patch. As tomorrow 
> is a national day, it should be ready friday.
Can you try creating some mutually recursive pagetables (i.e., one 
linearly maps the other, and vice versa) and then try ''xm
destroy''ing
the domain?

  -- Keir


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

Keir Fraser wrote:
>
> On 24 May 2006, at 21:12, Mathieu Ropert wrote:
>
>> Ok, i''ve done a little patch which seems to resolve the issue
on my
>> test setup. Basically, i''ve modified get_linear_pagetable(),
added a
>> level parameter and call it for each level but level 1.
>> I need to do a little more test before i post the patch. As tomorrow 
>> is a national day, it should be ready friday.
>
>
> Can you try creating some mutually recursive pagetables (i.e., one 
> linearly maps the other, and vice versa) and then try ''xm
destroy''ing
> the domain?
>
>  -- Keir
>
Here''s the patch that solves my issue. I''ve only tested it for
x86_64,
so any feedback on x86/PAE would be appreciated.
Tried to make mutually recursive tables and destroy the domain as you 
suggested, no problem encountered.
Note that the union i used may seem a bit overkill, but i didn''t saw
any
other way to make it generic (even if brutal casting should work on any 
x86/x86_64 arch).
Applies to cset 10166.

Mathieu

Signed-off-by: Mathieu Ropert <mro@adviseo.fr>




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

Keir Fraser wrote:
>
> On 24 May 2006, at 21:12, Mathieu Ropert wrote:
>
>> Ok, i''ve done a little patch which seems to resolve the issue
on my
>> test setup. Basically, i''ve modified get_linear_pagetable(),
added a
>> level parameter and call it for each level but level 1.
>> I need to do a little more test before i post the patch. As tomorrow 
>> is a national day, it should be ready friday.
>
>
> Can you try creating some mutually recursive pagetables (i.e., one 
> linearly maps the other, and vice versa) and then try ''xm
destroy''ing
> the domain?
>
>  -- Keir
>
Here''s the patch that solves my issue. I''ve only tested it for
x86_64,
so any feedback on x86/PAE would be appreciated.
Tried to make mutually recursive tables and destroy the domain as you
suggested, no problem encountered.
Note that the union i used may seem a bit overkill, but i didn''t saw
any
other way to make it generic (even if brutal casting should work on any
x86/x86_64 arch).
Applies to cset 10166.

Mathieu

Signed-off-by: Mathieu Ropert <mro@adviseo.fr>





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

Is it still the case that we don''t support recursive mappings for PAE
page tables?  NetWare relies on recursive mappings in both PAE and
non-PAE modes.  The non-PAE mode is working well, but now that I''ve
statred working on running with PAE it appears I''m hitting this issue.

- Bruce

>>> On 5/23/2006 at 3:52 AM, in message
<9e623acb8c30c70453a9b82b8b9a63b7@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:
> On 23 May 2006, at 10:41, Ian Pratt wrote:
> 
>> Can you explain the pagtable structure a little better please. Does
the
>> L3 contain an entry point at itself (recursive), or at another L3
>> (foreign)?
>>
>> I''ve never come across non-root pagetable linear mappings
other than
in
>> the crock that is PAE (3 level) where you have to use 4 entries in
an 
>> L2
>> to point to all the L2s due to the limited address space.
> 
> And that''s something we don''t currently support. A
slightly more
> generic linear pagetable logic that would permit us to support linear
> pagetables on PAE would be a good thing.
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel