double kernel page table entry for the same physical page?!

double kernel page table entry for the same physical page?!

[ming lei]

1. In PPC MMU_init sets up kernel page table for all
the physical pages available(say size is A) to the
virt address starting from PAGE_OFFSET to
(PAGE_OFFSET+A).

Question: does the linux ever touch this section of
page table(virt address from PAGE_OFFSET to
PAGE_OFFSET+A) again? like remove or modify one of the
entry?

2. In VMALLOC, say we have virt address
B(B>PAGE_OFFSET+A), sets up the page table entry for
this B to any one of the physical pages.

Question: For every physical page, it should already
be mapped in #1, but vmalloc maps it again to a virt
address higher. Does it mean in kernel page table, we
may have two PTE entries pointing to the same physical
page, even their virt addresses are different?

Last question:
If this is true, is this platform implemention
specific? Does i386 implemention have same situation?

Thanks,
Ming



		
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
 

Re: double kernel page table entry for the same physical page?!

[Dan Malek]

On Jul 13, 2005, at 1:10 PM, ming lei wrote:

> Question: does the linux ever touch this section of
> page table(virt address from PAGE_OFFSET to
> PAGE_OFFSET+A) again? like remove or modify one of the
> entry?

Not usually.  We used to do it on 8xx for mapping
uncached pages for coherent DMA.

> Question: For every physical page, it should already
> be mapped in #1, but vmalloc maps it again to a virt
> address higher. Does it mean in kernel page table, we
> may have two PTE entries pointing to the same physical
> page, even their virt addresses are different?

Yep.

> Last question:
> If this is true, is this platform implemention
> specific? Does i386 implemention have same situation?

Other architectures will do the same, yes.  The
level to which they do this will vary depending upon
architectural features we have to hide/expose to
other functions.

One potential problem that arises is you have to be
careful about the virtual address access path to these
pages.  All processors will behave errantly if you
access the same physical page, but with different
attributes, through the different VAs.  How they behave
will depend upon the attributes.  If the PTEs have
different cache modes or page sizes, it's usually
a big problem.  If they just share different write
permissions, it's usually OK.  These problems usually
arise when device driver writers either don't understand
the mapping issues or try something that may work
on one architecture but not on another.


	-- Dan

Re: double kernel page table entry for the same physical page?!

[ming lei]

I am worried about memory corruption if there are two
PTE entries point to the same physical page.
Considering this case: vmalloc a page to a virt
address V1 and somehow other code uses V0(which is in
identy mapping) to modify the same physical page.

I checked i386 and looks like they have the same
problem.

Why linux kernel does such thing and no one consider
it's a problem? 

Thanks
Ming

--- Dan Malek <dan@embeddededge.com> wrote:

> 
> On Jul 13, 2005, at 1:10 PM, ming lei wrote:
> 
> > Question: does the linux ever touch this section
> of
> > page table(virt address from PAGE_OFFSET to
> > PAGE_OFFSET+A) again? like remove or modify one of
> the
> > entry?
> 
> Not usually.  We used to do it on 8xx for mapping
> uncached pages for coherent DMA.
> 
> > Question: For every physical page, it should
> already
> > be mapped in #1, but vmalloc maps it again to a
> virt
> > address higher. Does it mean in kernel page table,
> we
> > may have two PTE entries pointing to the same
> physical
> > page, even their virt addresses are different?
> 
> Yep.
> 
> > Last question:
> > If this is true, is this platform implemention
> > specific? Does i386 implemention have same
> situation?
> 
> Other architectures will do the same, yes.  The
> level to which they do this will vary depending upon
> architectural features we have to hide/expose to
> other functions.
> 
> One potential problem that arises is you have to be
> careful about the virtual address access path to
> these
> pages.  All processors will behave errantly if you
> access the same physical page, but with different
> attributes, through the different VAs.  How they
> behave
> will depend upon the attributes.  If the PTEs have
> different cache modes or page sizes, it's usually
> a big problem.  If they just share different write
> permissions, it's usually OK.  These problems
> usually
> arise when device driver writers either don't
> understand
> the mapping issues or try something that may work
> on one architecture but not on another.
> 
> 
> 	-- Dan
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: double kernel page table entry for the same physical page?!

[Dan Malek]

On Jul 13, 2005, at 2:48 PM, ming lei wrote:

> Why linux kernel does such thing and no one consider
> it's a problem?

Because we don't write software that accesses the memory
from both of those locations, unless it is very intentional
and necessary.  If you are just fishing for ways software
_could_ do bad things, there are tons of them.  It's our
job to write it so it doesn't :-)

Thanks.


	-- Dan

Re: double kernel page table entry for the same physical page?!

[ming lei]

Dan,

No one intents to make memory corruption in kernel
space but it happens sometimes.

Say I have a global var in my kernel module which
called test-mod, it picks up a physical page allocated
by some code with  kmalloc and later kfreed(suppose
when it does, the whole page gets freed). But then
this code forgets a pointer(which maped to this
physical page) already freed and modifies the pointer,
the write gets thru since that virt address's PTE
still valid and points to the physical page currently
used by test-mod. So the memory corruption happens.

Maybe I miss something in the linux kernel code that
prevents this double PTE thing.

Ming

--- Dan Malek <dan@embeddededge.com> wrote:

> 
> On Jul 13, 2005, at 2:48 PM, ming lei wrote:
> 
> > Why linux kernel does such thing and no one
> consider
> > it's a problem?
> 
> Because we don't write software that accesses the
> memory
> from both of those locations, unless it is very
> intentional
> and necessary.  If you are just fishing for ways
> software
> _could_ do bad things, there are tons of them.  It's
> our
> job to write it so it doesn't :-)
> 
> Thanks.
> 
> 
> 	-- Dan
> 
> 



		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 

Re: double kernel page table entry for the same physical page?!

[Pantelis Antoniou]

ming lei wrote:
> Dan,
> 
> No one intents to make memory corruption in kernel
> space but it happens sometimes.
> 
> Say I have a global var in my kernel module which
> called test-mod, it picks up a physical page allocated
> by some code with  kmalloc and later kfreed(suppose
> when it does, the whole page gets freed). But then
> this code forgets a pointer(which maped to this
> physical page) already freed and modifies the pointer,
> the write gets thru since that virt address's PTE
> still valid and points to the physical page currently
> used by test-mod. So the memory corruption happens.
> 
> Maybe I miss something in the linux kernel code that
> prevents this double PTE thing.
> 
> Ming
> 

If you want to guard against stuff like this you have
some options...

1) Run different services on the same cpu on a a hypervisor
   like Xen.

2) Run most of the module's code in user space, and keep
   kernel space code to a minimum.

3) Use QNX.

Regards

Pantelis