* A Hardware Architecture for Implementing Protection Rings
* Authors: M.D. Schroeder and Jerome H. Saltzer
* Field: OS/Protection

Half of the paper describes the idea of protection rings for access
control in Multics.  Each segment has associated with it an access
control list (ACL) that specifies the users who have access to the
segment.  For each user, the segment's ACL specifies whether the user
can read, write, and execute the contents of the segment.  These
access capabilities constitute a "domain."

A process may be executing in different domains depending on the
current program being run (processes in Multics correspond to users).
Ideally the access capabilities of each domain would be completely
independent, according to the principle of least privilege.
Protection rings strike a balance between this ideal and the need for
efficiency and simplicity.  In a ring system the domains are strictly
ordered by access capability.  The 0th protection ring corresponds to
the most access; and Nth ring corresponds to the least.

Instead of flags for read/write/execute permission, each segment
(logically) stores the highest ring in which the process must be
executing in order to have access to the segment for that type of
access.  The rings allowed for each access type are called the
"bracket" for that access type.  For example, if a segment has user
Andy and stores the highest ring numbers for Read as 4, then the Read
bracket consists of rings 0-4.

Domain transfers (i.e. changing the ring of execution of a process) is
carefully controlled because of the possibility of gaining more access
privileges.  Suppose a process is in ring R.  If a process transfers
control to a segment whose top execute ring for that process is S < R
(a "downward" call), then the transfer of control proceeds to a
"gate."  There is a gate list associated with each segment.  The gate
then has complete control over how the access capabilities of the new
lower ring are used.  A semi-minor detail: the execute bracket is
augmented with a "gate extension" that specifies the execution rings
from which the gate can be called.  This way access to control
transfer to a gate is restricted.  Gates are analagous to the
user-accessible system call interface provided by a typical unix-like
OS.  The procedures that make up this interface must be careful to
protect against bogus arguments and carefully control use of the
processor's unrestricted supervisor mode.  Gates perform similar
argument and access protection for downward calls, with the help of
specialized hardware that validates address references.

Upward calls (i.e. to higher-numbered rings, with less access) do not
have to proceed through gates since the upward ring has strictly less
access.  Two problems arise in upward calls: arguments passed might
not be accessible to the higher ring, and the return to the lower ring
must proceed through a gate.  These cases are handled through a trap
to the supervisor instead of through the ring protection hardware.

Observation: the actual description of the hardware is less
interesting and insightful because it is tied to the particular
organization of MULTICS.  Also, it isn't clear how to design an
application to make good use of rings.

Is the complexity worth it?  Do rings strike a good balance between
efficiency, simplicity, and protection?  In particular, if a
particular application is really important enough to require
protection domains, are the tradeoffs inherent in rings acceptable
(esp. nested access permissions)?