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

1995). A dedicated process is in charge of the
memory space allocation, reallocations and free.
The process is executed in user mode; thus, the
page faults are forwarded and handled in user mode
and cannot cause a kernel bug. Moreover, most of
the kernel services are implemented outside the
kernel and specifically the device drivers; hence
these services are executed in user mode and are
not able to use the kernel stack.
Although the microkernel has many theoretical
advantages (Hand et al., 2005), its performance
and efficiency are somewhat disappointing. Nowa-
days, most of the modern operating systems use
a monolithic kernel. In addition, even when an
operating system uses a microkernel scheme, there
still will be minimal use of the kernel stack.
We propose an approach that suggests a dy-
namically growing stack. However, unlike the
microkernel approach, we will implement the
dynamically growing stack within the kernel.

execution thread. This thread is fully preemptive
hence real-time tasks are never delayed by non-
real-time operations.
Another interesting solution for a high-speed
kernel-programming environment is the KML
(Kernel Mode Linux) project (Maeda, 2002a),
(Maeda, 2002b), (Maeda, 2003). KML allows
executing user programs in kernel mode and a
direct access to the kernel address space. The
kernel mode execution eliminates the system call
overhead, because every system call is merely a
function call. The main disadvantage of KML is
that any user can write to the kernel memory. In
order to trim down the aforementioned problem,
the author of KML suggests using TAL (Typed
Assembly Language) which checks the program
before loading. However, this check does not al-
ways find the memory leak.As a result, the security
is very poor. It is difficult to prevent illegal memory
access and illegal code execution. On occasion,
memory illegal accesses are done deliberately, but
they also can be performed accidentally.
Our approach to increase the soft real-time
applications responsiveness is to run them as
kernel threads while using fundamental normal
process facilities such as a large and dynamically
growing stack. While running in kernel context,
it is possible to achieve a better predictive re-
sponse time as the kernel is the highest priority
component in the system. The solution provides
the most important benefits you find in the KML
project, although this solution is a more intuitive
and straightforward implementation.

real time considerations

Linux is designed as a non-preemptive kernel.
Therefore, by its nature, is not well suited for
real time applications that require deterministic
response time.
The 2.4.x Linux kernel versions introduced
several new amendments. One of them was the
preemptive patch which supports soft real-time
applications (Anzinger and Gamble, 2000). This
patch is now a standard in the new Linux kernel
versions (Kuhn, 2004). The objective of this
patch is executing the scheduler more often by
finding places in the kernel code that preemptions
can be executed safely. On such cases more data
is pushed onto the kernel stack. This additional
data can worsen the kernel overflow problem.
In addition, these cases are hard to be predicted
(Williams, 2002).
For hard real-time applications, RTLinux
(Dankwardt, 2001) or RTAI (Mantegazz et al.,
2000) can be used. These systems use a nano-
kernel that runs Linux as its lowest priority

implementation

The objective of this implementation is to sup-
port the demand paging mechanism for the kernel
mode stack. The proposed solution is a patch for
the kernel that can be enabled or disabled using
the kernel configuration tools. In the following
sections the design, implementation and testing
utilities are described.