Multics Protection Rings: Gates, Cross-Ring Calls, and the Honeywell 6180

Multics protection rings were not merely a ladder of processor modes. They let one process move between nested execution domains while preserving a controlled interface to more privileged code. A protected procedure could hold authority its caller lacked, but the caller reached it only through designated entry points, called gates. Segment descriptors and processor checks enforced the boundary.

The design evolved across distinct implementations. Multics’ protection plan was laid out in the mid-1960s; rings were first implemented with software assistance on the GE-645. Michael Schroeder and Jerome Saltzer’s August 1971 paper then described a hardware design for a Honeywell 6000-series machine. A 1972 project retrospective discussed a 6080-based hardware plan, while a spring 1973 MIT snapshot identified the running Multics system as a Honeywell 6180. Keeping those dates and labels attached to their sources avoids turning a proposal, a technology base, and an installed configuration into one supposedly simultaneous event.

A ring was an execution domain, not a simple user/supervisor bit

Multics addressed memory through segments. A virtual address identified a segment and a word within it; the process’s descriptor segment mapped that reference and recorded access controls. The processor consulted descriptors when it translated and checked references. This put the permission decision beside the address mapping instead of relying only on a convention inside each program.

The ring model added multiple, hierarchically ordered access domains to that segmented address space. A Multics process had rings numbered 0 through 7: ring 0 had the broadest access set, while ring 7 had the narrowest. The sets were nested. If a segment’s descriptors permitted a class of access only through a particular ring bracket, executing outside that bracket could not obtain that permission by issuing an ordinary load, store, or instruction fetch.

This differs from the later shorthand “ring 0 is the kernel and ring 3 is the application.” Multics had eight ordered rings; each ring related to a segment’s read, write, and execute brackets. The boundary was between procedures with different authority inside one process, not only between a user process and its supervisor.

Gates made the boundary callable

A protected subsystem was a collection of procedures and data intended to be used through selected entry points. It could, for example, keep a data structure inaccessible for direct reads while exposing a procedure that returned a limited result. The boundary was not just which ring could execute a segment, but where an outside caller could begin execution.

Multics called approved entry locations gates. A segment descriptor carried ordinary read, write, and execute controls as well as gate information. If code running in a less privileged ring attempted to enter a more privileged execution domain, hardware required the transfer to land on an authorized gate. A jump into an arbitrary instruction in the protected procedure was not equivalent to a valid call. The gate gave the subsystem a chance to check arguments, preserve invariants, and perform only the operations it intended to publish.

The call looked like a normal procedure call to its caller. The processor performed the additional boundary checks as part of the transfer rather than requiring a user program to construct its own privilege-switch sequence. In the proposed hardware, cross-ring calls and returns did not have to trap to a supervisor routine. That made the protected interface structurally similar to an ordinary procedure interface without making the two procedures equally trusted.

What happens at a cross-ring call

The essential transition can be summarized as a control transfer plus a new descriptor-enforced execution context:

Stage	Boundary rule	Result
Caller prepares a call	The target must be a permitted gate, not an arbitrary interior address in a more privileged segment.	The subsystem exposes a narrow entry surface.
Processor validates transfer	The destination and access-bracket rules are checked by the protection mechanism.	An invalid entry or forbidden reference is rejected rather than granted by caller convention.
Gate begins execution	Execution adopts the ring appropriate to the protected entry and segment.	The procedure has its intended authority; the caller does not simply inherit it.
Subsystem uses arguments	Hardware checks argument addresses as they are referenced to ensure the caller could access them.	A protected routine cannot be tricked into dereferencing a pointer that bypasses the caller’s access rights.
Procedure returns	The cross-ring return restores the caller’s execution context through the defined return mechanism.	Control resumes with the caller’s narrower authority.

The hardware check on an argument address is not the same as validating the argument’s meaning. Saltzer’s 1973 protection paper explicitly separates those jobs: hardware can establish that the caller is allowed to reference the memory, while the protected subsystem must still check value ranges and semantic rules. A gate that accepts a length, index, or operation code still needs to reject nonsensical or unauthorized values. Rings enforce an access boundary; they do not make every subsystem correct.

Why the GE-645 needed software help

The first Multics hardware base was the GE-645, with segmented virtual memory and descriptor-based access controls. Schroeder and Saltzer’s 1971 paper describes its processor as having only a limited set of access-control mechanisms for implementing rings, which forced software intervention for ring protection. The hardware could participate in segment translation and basic access checks, but the complete ring-transition design was not yet present in the processor.

The 1967 ring mechanism generalized the familiar supervisor-versus-user relationship so that user-written subsystems could be protected without being compiled into the supervisor. On the early machine, the software implementation provided the intended organization, but the transition required more work than the later hardware design. This distinction matters: “Multics had rings” does not mean every Multics machine enforced them with identical hardware from the beginning.

From a hardware proposal to the 6180 system

M0126, dated August 2, 1971, is a design paper, not a report that the new processor was already installed. Its authors describe a second iteration of the Multics hardware base, being built with Honeywell 6000-series technology, and explain how the processor would enforce rings and gate transfers. The paper treats the design as applicable to segmented systems generally, but its concrete motivation and examples are Multics.

The 1972 paper “Multics: The First Seven Years” describes a planned MIT hardware base for 1972. It says the base would use the circuit technology of the Honeywell 6080 and include protection rings in paging and segmentation hardware. A later MIT paper, written as a spring 1973 snapshot, identifies the operational Multics system as running on the Honeywell 6180. These statements should be read with their own time perspective: the 1972 paper describes a planned base and technology; the 1973 paper describes the identified running configuration. The 6180 designation refers to the Multics-compatible system in the later account, not evidence that every 6080 configuration already contained the same ring mechanism.

In a January 1974 report, Saltzer and colleagues said that during the 645-to-6180 transition, software that simulated rings was removed in favor of 6180 hardware support. They reported that ring-switching processor time fell from about three milliseconds to fifteen microseconds. That is a historical measurement reported for this transition, not a general benchmark for every Multics workload. The same report cautions that the overall performance gain was initially modest because software rings had already led designers to minimize how often the system crossed rings. Hardware support’s larger prospective benefit was freedom to reorganize central code without making every boundary crossing prohibitively expensive.

What the design did and did not promise

Rings provided a tractable hierarchy, but not every possible access policy. The design traded arbitrary domain relationships for an ordered structure that could be checked efficiently. Schroeder and Saltzer discussed generality, economy, simplicity, and programming convenience as competing criteria, not qualities one mechanism could maximize simultaneously.

Nor did a gate make a subsystem invulnerable. A gate procedure could contain a logic error, mishandle a length, or expose too much authority through its own API. Hardware could authenticate the entry point and check references, but developers still had to reason about the subsystem’s state and arguments. The protection mechanism made the interface enforceable; it did not prove that the interface was well designed.

Historical resemblance does not by itself establish direct influence on a later processor or operating system. The MIT papers document Multics’ model and implementation path; they do not make it a simplified version of a modern CPU privilege scheme.

The enduring systems lesson is architectural: if a trusted service must operate with more authority than its caller, expose a deliberate entry point and make the transition part of the execution contract. Multics combined that interface with segment-level read, write, and execute controls, ordered rings, hardware-checked gates, and returns that restored the caller’s context. The GE-645-era software implementation and the later 6180 hardware show the same protection objective under two different enforcement costs.

Related:

Sources: