The notion of rings required hardware support, which for Multics was provided by the Honeywell 645 computer. Hardware support for the basic notion of rings is also supported by the PC architecture (Intel 286 and beyond).
PC rings differ from the Multics rings in several ways:
The PC got rid of b2, whose purpose is to allow ungated access to a segment from segments of less privilege. It is not clear we need this flexibility; as we see above, the values of b1 and b2 are the same in all of the examples.
In Multics, the limit, b3, is the same for all gates (entry procedures). PC allows each gate to determine its limit. Thus, the limits is stored, not with the segment descriptor, but with a special gate descriptor. Here is my understanding of what happens. The gate descritor is associated with its own segment number, l, which serves as its limit. A call is allowed to a gate as long as the caller's segment is within the limit, and the caller's ring number is changed to the ring no. of the segment. (The PC book I read seemed to imply that the ring no. of the segment cannot be smaller than the limit, in which case we would not have amplification. But it says there is amplification, so I am going to assume that the ring no. of the segment can be anything.)
A separate stack is created when amplification occurs. If it was not, a caller of less privilege (hence untrusted) could allocate too small a stack space for a called procedure of more privilege, thereby corrupting the more trusted level.
Multics protected "direct" accesses to a segment. However, it was possible to do illegal indirect accesses. Assume, a segment s1 invokes a procedure, p, in a more privileged segment, s2, passing it an address, a. Now s2 may be able to access a in ways s1 could not potentially violating security constraints. For instance, p may be a procedure that copies data into a, and s1, the creator of a, may have no access to a because it refers to data in a more privileged segment. To prevent this situation, the PC records in an address, a, the ring number of the object that created a. The effective ring number of a process p trying to access address a is the larger of the current ring number of the process and the ring number of a.
In some cases, when a process executes a segment, its ring number is not changed to the ring number of the segment. If the segment is typed as "conforming" segment, the ring number is unchanged. Exception handlers and libraries not requiring special privilege are meant to be put in conforming segments
The ring schemes allow amplification, but still had the disadvantage that the ring (hierarchical) structure did not allow enforcement of the need-to-know principle. If an object was to be accessible in ring i, but not in j, then it was necessary that i < j. But this meant that every object accessible in ring j was accessible in ring i. The ring scheme is particularly useful in layered systems, where successively lower layers require higher privilege. For instance, the PC ring mechanism is meant to allow ring 0 to contain memory management, process management, device I/O, and interprocess communication; ring 1 to contain display management, and file management, ring 2 to contain custom extensions of the OS such as network file system, and ring 3 to contain user routines.