Linux Systems - Modes of Operation (Kernel & User)
Brett Lee
=============================================================================

To discuss modes of operation, we'll need to cover the following:

CPU Modes
System Calls
Mode Switch vs. Context Switch


* CPU Modes
*****************

Processors are capable of operating at different levels of privledge - it's up
to each operating system how they want to utilize the levels.  Typically, there
exists one "real" mode and at least one "protected" mode, with the protected
mode possibly simulating a "ring" of escalating privledges.  A couple examples
of these processors are the Motorola 68000 (containing two modes) and the Intel
processors (containing four).  Intel refers to these modes as Rings, with Ring
0 being the most "real." Although Unix may be executing on a CPU with four
different modes, the Unix operating system creates only two modes, kernel and
user.

The kernel, the core of the operating system, contains the routines necesary
for multiple applications to safely access hardware devices, memory, and
filesystems without stepping all over each other.  When the processor executes
in kernel mode, it is executing with a full set of privledges and access.
Applications, on the other hand, are not trusted very much and thus execute in
user mode.  Applications can, by means of system calls, request the kernel to
perform the critical task of accessing the hardware.  But they cannot do it
themselves.  This seperation provides a measure of protection for the system,
as the kernel can enforce guidelines into what commands execute and thus
severely restrict dangerous operations to "valid" code.

To repeat, applications are not allowed to cross the addressing space into
kernel mode, so to attempt risky operations (like interacting with the
hardware) they must go through the kernel.



Below is an example from:

  http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-3.html



                      
               |          Applications           /|\
               |         ______________           |
               |         | User Mode  |           |  
               |         ______________           | 
               |               |                  |  
Implementation |        _______ _______           |   Abstraction
    Detail     |        | Kernel Mode |           |
               |        _______________           |
               |               |                  |
               |               |                  | 
               |               |                  |
              \|/          Hardware               |



More info about this and Kernel Mode Linux can be found here:

  http://www.linuxjournal.com/article/6516






* System calls
*********************

Linux is designed in such a way that to execute risky operations, the execution
must occur in "kernel mode" accomplished by the use of "system calls."  In the
Linux kernel, the system call execution specifics (sysenter/sysexit) have
changed from 2.4 to 2.6 to utilize newer hardware which speeds up the process,
however the general approach of using system calls has not changed.



In short, a system call has an API that developers use, is provided by a system
library (e.g. libc), and it knows how to signal (interrupt) the kernel to

 a) switch the processor to Kernel Mode, and
 b) safely execute the instruction using routines in the kernel. 



Here is another example, from:

    http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-3.html



                                 |                |
                         ------->| System Call i  | (Accessing Devices)
|                |       |       |  [sys_read()]  |
| ...            |       |       |                |
| system_call(i) |--------       |                |
|   [read()]     |               |                |
| ...            |               |                |
| system_call(j) |--------       |                |  
|   [get_pid()]  |       |       |                |
| ...            |       ------->| System Call j  | (Accessing kernel data structures)
|                |               |  [sys_getpid()]|
                                 |                | 

    USER MODE                        KERNEL MODE


As you can see, the User Mode System Calls are the interface to Kernel routines.
Note that the Kernel routines (currently) begin with sys_*.  Older UNIX's may
have began with "_*".

Here are a few more examples:

System call		: Corresponding kernel routine
=-=-=-=-=-=-		 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

time			: sys_time
stime			: sys_stime
gettimeofday		: sys_gettimeofday
settimeofday		: sys_settimeofday
adjtimex		: sys_adjtimex

As of this writing, the syscalls are listed in:

  /usr/src/kernels/<version>/include/asm/unistd.h




* Mode Switch vs. Context Switch
**********************************

As discussed above, the CPU has two modes - User and Kernel.  When an 
application executing in User mode executes a system call, the CPU switches to
Kernel mode and executes the instructions.  This switch in CPU state is called
a mode switch, and the CPU now has more "power" (access to all the memory
locations and other system resources).  The mode switch does not change the
instructions that are executing, it simply changes its mode of execution.

By contrast, a context switch DOES change the instructions that are executing.
A context switch is the function of a multitasking operating system, and
allows the instructions from one process or thread to be replaced by another
set of instructions.  This typically involve moving the current state
(switchframe) from the CPU's registers, replacing it with another switchframe.
In the switchframe is a program counter that indicates the location where to
restart begin execution, thus the "context" is the combination of the registers
plus the program counter (a specialized register).

In closing, its interesting (and obvious once you think about it) that a
context switch can only occur in kernel mode.  Thus, every context switch
involves a mode switch also.  Mode switches are relatively slow events, so
system calls should be avoided in leiu of the API whereever possible.  But,
context switches are hard to avoid.  Clearly a mode switch is not as CPU
intensive as a context switch, but with many context switches each second,
the net effect of these two really can chew up those nanoseconds of CPU time.

For an idea of how many context switches actually happen, grab DTrace and
take a look.  Hopefully that nice tool will be available for Linux soon.






* The rest is up to you -
******************************

  System Calls:
  man 2 intro

  Implementing System Calls:
  http://www.linuxjournal.com/article/3326

  Kernel Programming:
  http://www.linuxhq.com/lkprogram.html

  Secure Programming for Linux and Unix HOWTO:
  http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html

  Lots of high level info:
  http://www.linux.com/base/ldp/howto/HOWTO-INDEX/programming.html