Information Technology Reference
In-Depth Information
with less than complete access to the full power of the hardware. Figure 2.1
illustrates this difference between kernel-level and user-level execution.
In turn, applications themselves often need to safely execute untrusted third
party code. An example is a web browser executing embedded Javascript to
draw a web page. Without protection, a script with an embedded virus can take
control of the browser, making the user think they are interacting directly with
the web when in fact their web passwords are being forwarded to an attacker.
This design pattern | extensible applications running third party scripts |
occurs in many different domains. Applications become more powerful and more
widely used if third party developers and users can customize them, but that
raises the issue of how to protect the application itself from rogue extensions.
In this chapter we focus on how the operating system kernel against rogue
applications, but the principles also apply at the application level.
A process is the abstraction for protection provided by the operating system
Definition: process
kernel: the execution of an application program with restricted rights. A process
needs permission from the operating system kernel before accessing the memory
of any other process, before reading or writing to the disk, before changing
hardware settings, and so forth. In other words, a process's access to hardware
is mediated and checked by the operating system kernel. In this chapter, we
explain the process concept and how the kernel implements process isolation.
A key consideration is that we need to provide protection while still running
application code at high speed. The operating system kernel runs directly on
the processor with unlimited rights. The kernel can perform any operation
available on the hardware. What about applications? They need to run on
the processor with all potentially dangerous operations disabled. To make this
work, we will need a bit of assistance from hardware, which we will describe
shortly. Throughout the topic we will see examples of this | small amounts
of carefully designed hardware can help make it much easier for the operating
system to provide what users want.
Of course, both the operating system kernel and application processes run-
ning with restricted rights are in fact sharing the same machine | the same
processor, the same memory, and the same disk. When reading this chapter,
it is helpful to keep these two perspectives in mind: sometimes, when we are
running the operating system, the system can do anything, and at other times,
when we're running an application process on behalf of a user, the behavior is
restricted.
Thus, a processor running an operating system is somewhat akin to someone
with a split personality in charge of their own insane asylum. When running the
operating system kernel, the processor is like a warden with complete access to
everything. At other times, the processor runs application code in a process |
the processor becomes the inmate, wearing a straightjacket locked in a padded
cell by the warden, protected from harming anyone else. Of course, it is the
same processor in both cases, sometimes completely trustworthy and at other
