bzImage -> vmlinux?

Ian Molton spyro at f2s.com
Tue Jul 13 19:38:03 PDT 2004


On Wed, 14 Jul 2004 02:20:56 +0000
Bennett Todd <bet at rahul.net> wrote:

> 
> > but if the pages were mapped read only to userspace, it would work
> > fine as it would all be executing in user context.
> 
> I see it not as a question of context --- overrunning buffers is bad
> wherever you do it.
> 
> I see it as a question of control of inputs.

You're approach is wrong. You need to understand how memory is managed
in Linux.

Basically:

Memory as seen by the code in a linux machine is all virtual, and also
broken up into regions called pages.

(Including the area the kernel sits in (Im trying to avoid architecture
specifics here so please no one comment about that).

There is a mapping between virtual pages and physical pages that
actually exist on RAM chips.

The mapping is defined by the kernel, and enforced by the MMU (memory
management unit).

it is possible to map pages more than once so that many virtual pages
map to the same physical page (but not vice-versa, as that isnt useful).
Pages also have a protection level, and can be (minimally) read only,
read write, or inaccessible.

The kernels pageas are known as 'direct mapped' and the distinction is
that unlike userspace, which I will get to in a moment, they are
*always* visible in the memory map.

Userspace is different. each time a context switch occurs, a different
'set' of logical -> virtual mappings cover userspace, which is how we
can run multiple processes - all the userspace processes think they are
the only thing on the machine, and that their address space starts from
the same (virtual) address.

The kernel can (selectively) choose to allow two programs to 'share'
physical pages, by allowing them both to make a range opf their logical
address space map onto the same range of physical addresses (shared
memory), and can also decide wether to make any page (shared or
nonshared) read only, read write, or inaccessible, from the point of
view of any process.

the kernel *code* is always read only to userspace, as is its data.\

Userspace applications cant mess with each other because they cant
change the virtual->physical mappings or page protections and thus
cannot write outside their bounds (the MMU will trap these attempts and
you get a segfault).

so in theory there is no reason the kernel cant export code to userspace
in a read-only fashion.

the issue about buffer over-runs is moot because all data would be on
the user processes own stack, and all memory allocations would be made
from the same.

Phew. pretty long for a basically... hope this is usefuil to someone...



More information about the lfs-chat mailing list