From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Mon Jan 12 2004 - 15:02:51 PST
The relevant contributions in this paper were concerned with the use of
capability lists to control access to operating system resources, and
the new synchronization "meta-instructions" provided by the OS, which
abstract the notion of parallel computation.
The protection mechanism conceived in this paper introduces the concept
of capability lists. A C-list (also affectionately known as a sphere of
protection) is a list of <access-mode, object reference> pairs which
form a context around a set of executing abstractions called processes.
The objects being referenced here may be segments, printers, etc. The
set of <c-list, set of processes> construct is known as a computation in
this paper. The computation is akin to the modern process and the MCS
process is similar to the modern-day thread. The paper introduces the
notion of a dynamic execution context with regards to the executing
processes. This execution context determines what resources are
available to the execution at any given time.
The concept of a debug-able system is also presented in this paper.
Because the c-list itself is a resource, c-lists can reference other
c-lists. In this way a process can control the dynamic context of
execution of another process (i.e. debug the second). This is a useful
contribution made by this paper.
An attempt was made in this paper to create a coherent mechanism for
handling exceptions. The concept is that a new process (keep in mind
that these were light-weight), was created in the current computation.
The process that threw the exception is suspended. The new process is
then responsible for "making things right," and either continuing or
terminating the faulting process. I believe that the complexity of this
exception management system was too high for it to endure into modern
systems. The modern concept of exception handling occurring in the same
process but potentially at a higher level in the call stack is more
flexible and has access to more of the state required to handle the
exception.
The interesting notion of "protected entry points" is presented in the
paper, which allow synchronized access to an underlying resource via a
special, reserved execution context (a c-list belonging to the resource
itself). When the caller wants to access a resource, the execution
passes into the new execution context and that context controls access
to the resource. This idea is a good one in the sense that it
compartmentalizes access to the underlying resource. I would be very
interested in the performance implications of implementing this
abstraction.
The directory structure put forth was an extension of the protection
mechanism to "retained objects," i.e. objects that would be saved in a
permanent store. Resource ownership is embodied in the naming system
and begins at the user's root directory, which specifies the tree of
capabilities (to underlying objects) granted unto the user. The
relevant question that comes to my mind is, how is the mechanism put
forth in MCS different from that in MULTICS and what are the benefits
and drawbacks of each? This is a huge question, but must be answered if
one is to truly understand the two systems.
Predating the MULTICS paper, the MCS paper has weaknesses in its
protection mechanisms with regards to the directory structure.
Weaknesses stem from the fact that access rights are placed on the
naming system (the path to the resource) rather than on the underlying
resource itself (as is the case with ACL's). Recalling the three
weaknesses of capabilities put forth in the MULTICS paper: 1) revocation
of access is awkward due to the directory structure must be modified, 2)
differently named paths to the same resource yield different access
rights, resulting in a high degree of management complexity, and 3)
determining who has access to a resource is difficult because a
traversal of the directory namespace is necessary.
The MULTICS solution seems to scale better than the capabilities
solution as well. In MCS, an executing process needs to have entries in
its c-list for ALL OBJECTS its has access to. If there are many more
objects than there are users, the MULTICS system will scale better. In
addition the idea that object names cannot change seems weak.
Finally, this paper introduced a useful set of parallelizing primitives
(fork, join, quit, lock, etc.) which abstract the notions of multiple
executing processes (actually, light-weight processes, more like threads
really). These ideas are compatible with the semaphores introduced by
Dijkstra. The idea of independent executions synchronizing with each
via OS-supported joins does not seem to be a new idea here. The issue
of sharing objects via locks was presented in Dijkstra's mutexes. The
disabling of interrupts to avoid priority inversions was a distasteful
idea, killing scalability for the sake of liveness. I believe that both
requirements can more gracefully be fulfilled using finer-grained
locking. The idea of a process as a locus of control was introduced in
the Nucleus paper, so that's not new. The only really new idea here is
the sharing of private state with a process's child via the fork
command, which I believe is a minimal contribution at best. Therefore,
despite the endurance of these OS primitives, I don't believe there are
significant contributions in this area.
To surmise, this paper provided valuable contributions to the area of
capability-based protection systems, with process synchronization a
distraction to the fundamental theme.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 15:02:52 PST