\section{Execution Modes}

\begin{frame}
   {Two Execution Modes}

   \begin{itemize}
      \item User Mode
      \begin{itemize}
         \item Running with restricted privileges
      \end{itemize}
      \item System (or Kernel) Mode
      \begin{itemize}
         \item Running with full unrestricted privileges
      \end{itemize}
   \end{itemize}
\end{frame}

\cprotect\note{


   At any given time a process (or any particular thread of
   a multi-threaded process) may be executing in either
   \textbf{user mode} or \textbf{system mode}, which is
   usually called \textbf{kernel mode} by kernel
   developers.

   What instructions can be executed depends on the mode
   and is enforced at the hardware, not software, level.

   The mode is not a state of the system; it is a state of
   the processor as in a multi-core or multi-CPU system
   each unit can be in its own individual state.

   In \textbf{Intel} parlance, user mode is also termed
   \textbf{Ring 3} and system mode is termed \textbf{Ring
      0}.


}


\begin{frame}
   {User Mode}

   \begin{figure}[H]
      \includegraphics[width=5.0in]{IMAGES/syscall}
      \caption{User and Kernel Modes and System Calls}
   \end{figure}


   \begin{itemize}
      \item \textbf{User mode} has fewer privileges than \textbf{kernel mode}
      \item Regular program code executes in this mode
   \end{itemize}

\end{frame}

\cprotect\note{

   Except when executing a \textbf{system call} (described
   in the next section) processes execute in \textbf{user
      mode}, where they have lesser privileges than in
   kernel mode.

   When a process is started it is isolated in its own user
   space to protect it from other processes.  This promotes
   security and creates greater stability. This is
   sometimes called \textbf{process resource isolation}.

   Each process executing in user mode has its own memory
   space, parts of which may be shared with other
   processes; except for the shared memory segments, a user
   process is not able to read or write into or from the
   memory space of any other process.

   Even a process run by the root user or as a setuid
   program runs in user mode except when jumping into a
   system call, and has only limited ability to access
   hardware.

}


\begin{frame}
   {System (Kernel) Mode}

   \begin{itemize}
      \item Entered when a program makes a system
      call
      \item Lasts until the system call exits
      \item More privileges than user mode
      \item Processes in system mode are running kernel code
      \begin{itemize}
         \item Obtaining disk access (read,
         write)
         \item Requesting additional
         memory(brk, sbrk)
         \item Changing the current working
         directory (cd)
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   In system (kernel) mode the CPU has full access to all
   hardware on the system, including peripherals, memory,
   disks, etc.  If an application needs access to these
   resources it must issue a \textbf{system call}, which
   causes a \textbf{context switch} from user mode to
   kernel mode.  This procedure must be followed when
   reading and writing from files, creating a new process,
   etc.

   Application code never runs in kernel mode, only the
   system call itself which is kernel code.  When the
   system call is complete, a return value is produced and
   the process returns to user mode with the inverse
   context switch.


   There are other times when the system is in kernel mode
   that have nothing to do with processes, such as when
   handling hardware interrupts or running the scheduling
   routines and other management tasks for the system.

}



