The Exokernel Operating System and Active Networks - Advanced Operating Systems and Kernel Applications - page 143

ating System. The aspects that we have chosen to
look at are by no means a comprehensive list, but
they are intended to leave the reader with a good
understanding of the Exokernel's approach.

retains this authority until it gives it up (Engler,
Kaashoek, & O'Toole, 1995). The Exokernel is
only minimally involved in this process as it only
provides the authorization to use the resource and
it does not get involved in the ongoing manage-
ment of the use of that resource.
Furthermore, the Exokernel can provide
secure-bindings without any special knowledge
of what it is binding. The semantics of binding
a resource to application software can get very
complex. However, the Exokernel does not get
involved in the details of the binding. It only
gets involved to the extent that it can provide the
security associated with that binding. As Engler,
Kaashoek, and O'Toole say, “a secure binding
allows the kernel to protect resources without
understanding them” (Engler, Kaashoek, &
O'Toole, 1995).

tracking ownership of resources

The allocation of a resource is actually accom-
plished by what the research group calls the Li-
brary Operating System (LibOS). This LibOS is
outside of the kernel; therefore the kernel is only
minimally involved. The kernel gets involved
just enough to record the ownership information
associated with a resource. For example, when
physical memory gets allocated, the kernel keeps
track of which process the resource has been al-
located to and which processes have 'read' and
'write' permissions (Engler, 1998). As a way to
retain its minimal involvement, the Exokernel
records resource allocations in what the research
group calls an open bookkeeping policy . Through
this open bookkeeping policy, as Engler explains,
resource allocation records are made available to
all user processes in read-only mode. This allows
the user processes to look-up for themselves if the
resource that they want is actually available. This
means the kernel does not need to be interrupted
by a process that keeps requesting a resource that
is currently unavailable.

revoking access to resources

Although a secure-binding, in theory, allows a
process to use a resource until it is done with
it - in reality, there still must be a way for the
operating system to force a revocation of the
resource binding under certain conditions. Un-
like the Exokernel, when a traditional operating
system brakes a resource binding it does so by
what is known as invisible revocation . With an
invisible revocation, the resource binding is simply
broken and the process has no knowledge of the
circumstances that prompted the revocation. A
disadvantage of using invisible revocation is that
operating systems “cannot guide de-allocation
and have no knowledge that resources are scarce”
(Engler, Kaashoek, & O'Toole, 1995).
When an Exokernel breaks a secure bind-
ing, it uses a technique that the researchers have
named visible revocation. With visible revoca-
tion, communication occurs between the kernel
and the process. Because of this communication,
the process is informed of the need to have the
resource binding broken. By being warned of the
resource revocation before the event, the process

ensuring protection by guarding all
resource usage or binding points

It is very important for a process to retain use of
a resource until it is done using it. For example, a
process should be able to securely use a block of
memory until the process decides to de-allocate
it. The Exokernel uses what are called “secure-
bindings” when binding a resource to a process.
A secure-binding separates the authorization to
use a resource from the actual use of that resource.
Authorization to use a resource is granted or de-
nied when the resource is first requested. Once
the process has the authority to use a resource, it