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
From: Dan Malek <hidden> Date: 2005-07-13 21:27:20
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
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:
quoted
Question: does the linux ever touch this section
of
quoted
page table(virt address from PAGE_OFFSET to
PAGE_OFFSET+A) again? like remove or modify one of
the
quoted
entry?
Not usually. We used to do it on 8xx for mapping
uncached pages for coherent DMA.
quoted
Question: For every physical page, it should
already
quoted
be mapped in #1, but vmalloc maps it again to a
virt
quoted
address higher. Does it mean in kernel page table,
we
quoted
may have two PTE entries pointing to the same
physical
quoted
page, even their virt addresses are different?
Yep.
quoted
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
From: Dan Malek <hidden> Date: 2005-07-13 22:36:29
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
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:
quoted
Why linux kernel does such thing and no one
consider
quoted
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
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