Kernel Stack Overflows Elimination - Advanced Operating Systems and Kernel Applications - page 5

StacK allocationS consists of two parts - one part maps the text,

the data and the heap section that typically oc-
cupy a continuous region at the beginning of the
memory; whereas the second part maps the stack
that occupy a region beginning at the end of the
virtual memory. This make a large “hole” in the
middle of the page table between the heap region
and the stack region and the page table is reduced
to just two main areas. Later systems have also
needs of dynamic libraries mapping and thread
support; therefore the memory segments of the
program are scattered over the virtual memory
address space. With the aim of mapping a sparse
address space and yet reducing the page table
size, most of the modern architectures make use
of a hierarchy page table. E. g. Linux uses a three
level architecture independent page table scheme
(Hartig et al., 1997). The tables in the lower levels
will be needed just if they map addresses that the
process accesses. E. g. Let us assume a hierarchy
page table of two levels that the higher level page
table contains 1024 pointers to lower level page
tables and each page table in the lower level also
contains 1024 entries. An address of 32 bits will
be split into 10 bits that will contain the index of
the higher level page table where a pointer to a
page table in a lower level will reside, more 10
bits that will contain an index to a lower level
page table where a pointer to the physical frame
in the memory will reside and 12 bits that will
contain the offset inside the physical page. If the
address space is mapped by 64 bits, two levels page
table will not be enough and more levels should
be added in order to reduce the page table into a
reasonable size. This may make the translation
time longer, but a huge page table will occupy too
much memory space and will be an unnecessary
waste of memory resources.

fixed Size allocations

User space allocations are transparent with a large
and dynamically growing stack. In the Linux
kernel's environment the stack is small-sized and
fixed. It is possible to determine the stack size
as from 2.6.x kernel series during compile time
choosing between 4 to 8KB. The current tendency
is to limit the stack to 4KB.
The allocation of one page is done as one non-
swappable base-page of 4KB. If a 8KB stack is
used, two non-swappable pages will be allocated,
even if the hardware support an 8KB super-page
(Itshak and Wiseman, 2008); in point of fact, IA-
32 machines do not support 8KB super-pages, so
8KB is the only choice.
The rational for this choice is to limit the
amount of memory and virtual memory address
space that is allocated in order to support a large
number of user processes.Allocating an 8KB stack
increases the amount of memory by a factor of
two. In addition the memory must be allocated
as two contiguous pages which are relatively
expensive to allocate.
A process that executes in kernel mode, i.e.
executing a system call, will use its own kernel
stack. The entire call chain of a process execut-
ing inside the kernel must be capable of fitting
on the stack. In an 8KB stack size configuration,
interrupt handlers use the stack of the process
they interrupt. This means that the kernel stack
size might need to be shared by a deep call chain
of multiple functions and an interrupt handler. In
a 4KB stack size configuration, interrupts have a
separate stack, making the exception mechanism
slower and more complicated (Robbins, 2004).
The strict size of the stack may cause an over-
flow. Any system call must be aware of the stack
size. If large stack variables are declared and/or
too many function calls are made, an overflow
may occur (Baratloo et al., 2000), (Cowan et al.,
1998).