Last updated: May 2004
.. under construction ..
Early history - including memory protection, multiple modes of execution, and privileged instructions.
Many of the seminal ideas, however, were widely spread by word of mouth or internal memorandum rather than by journal publication, and historical accuracy is sometimes difficult to obtain. In addition, some ideas related to protection were originally conceived in other contexts.
The concepts of base-and-bound register and hardware-interpreted descriptors appeared, apparently independently, between 1957 and 1959 on three projects with diverse goals. At M.I.T., J. McCarthy suggested the base-and-bound idea as part of the memory protection system necessary to make time-sharing feasible. IBM independently developed the base-and-bound register as a mechanism to permit reliable multiprogramming of the Stretch (7030) computer system. At Burroughs, R. Barton suggested that hardware-interpreted descriptors would provide direct support for the naming scope rules of higher level languages in the B5000 computer system.
-- from Saltzer and Schroeder, "The Protection of Information in Computer Systems," CACM, July 1974.
"McCarthy's essential insight was that both hardware interrupts and memory protection were needed to provide safe and efficient timesharing service. Memory protection also makes it easier to debug programs and to run programs with unkown integrity."
-- Les Earnest
Stretch used bounds registers to protect memory, and it used interrupts being enabled or disabled as essentially the mode bit. E.g., the bounds registers can be changed only when interrupts are disabled. However, the instruction to disable interrupts (branch disabled) can be executed by a user program. The Stretch designers relied on the compiler to prevent this instruction from being generated. (This same philosophy influenced the IBM 801 RISC design.)
"The modifications to the PDP-l to effect timesharing were embodied in the 'restricted mode' of operation. They matched the above requirements in the following way:
- Memory protection. Switching between the two 4-Kword areas required the use of an I/O instruction.
- Program and data relocatability. Because only one user was resident at one time, this was not needed.
- A supervisor program. The channel 17 clock routine fulfilled this function.
- A timed return to the supervisor. The channel 17 clock generated an interrupt every 20 milliseconds.
- Interpretive execution of I/O instructions. Whenever the PDP-l was in restricted mode, an attempt to obey an I/O instruction caused a sequence break [i.e., an interrupt]."
-- from Bell, et al., "The PDP-1 and other 18-bit computers," Bell, Mudge, and McNamara, chapter 6, pp. 140-141.
"The occurrence of any interrupt causes one of the system computer modules to leave the program it has been running and branch to the suitable AOSP entry, entering a control mode as it branches. The control mode differs from the normal mode of operation in that it locks out the response to some low-priority interrupts (although recording them) and enables the execution of some additional instructions reserved for AOSP use (such as setting an interrupt mask register or memory protection registers, or transmitting an I/O instruction to an I/O control module)."
-- from Anderson, et al., "D825 - a multiple-computer system for command and control," FJCC 1962, reprinted in Bell and Newell, chapter 36, p. 452
"The hardware RPQs that made CTSS run on MIT's 7094s added several instructions and a memory boundary register to the processor: in addition, the machines had two 32K core memory banks instead of one. Core bank A held the CTSS supervisor, and B Core was used for user programs. ... More importantly, the RPQ made the 7094 a two-mode machine. When the machine was running a program in B-core, many instructions were forbidden: executing them caused the machine to trap and take its next instruction from A-core. In particular, I/O instructions were forbidden, as well as attempts to switch core banks.
By convention, user programs called on supervisor services, such as the file system, by executing a TSX ADDR,4 where ADDR held TIA =HWRFLXA. The TIA instruction was illegal in B-core mode, so the CPU trapped into the A-core supervisor module named PMTI (Protection Mode Trap Interpreter), which looked up the BCD name of the supervisor entrypoint, found its location, and made the transfer."
-- from Tom Van Vleck, "The IBM 7094 and CTSS"
Five-bit storage keys were applied to each 2 KB block of main memory; four bits were matched to a four-bit field in the current PSW, while the fifth bit governed whether writes were prevented or both reads and writes were prevented (if the key didn't match the PSW). S/360 had a problem-state/supervisor-state bit separate from the interrupt permission/enable bits. Privileged instructions included load PSW, insert storage key, set storage key, set system mask, and several I/O-related instructions. [apparently most early S/360 systems only used the write prevention]
recent comp.arch traffic
Paul Repacholi writes
> Didn't the DEC KL-10 have "call gates" that were implemented > in just this fashion...?
The PORTAL intruction? That worked by triggering a MM fault on the fetch, which the PORTAL than stepped on before it got out of the Mbox. If you jumped to other than the PORTAL, the MM fault happened and got to the kernal. It was a bit odd in that it could controll access to code in user mode, that you could only execute, not read, and further, you could only enter it at specific points with out MM faulting.
Dale Morris writes:
PA-RISC implements this sort of mechanism in its GATEWAY instruction, which can be used to branch and promote to any of 3 privilege levels. The instruction TLB mapping (for the page containing the GATEWAY instruction) provides information on what privilege level to promote to, and whether the GATEWAY instruction is legal (GATEWAY instructions on normal code pages fault).
Itanium also implements a similar mechanism with the EPC instruction. It works similarly, but doesn't branch - it only does the privilege promotion. In Itanium, privilege can also be changed on a normal br.ret, allowing system call code to simply return to the calling process. However, since the privilege to return to is stored in an unprivileged register, we also had to guard against an application trying to spoof a system call into returning at high privilege. Therefore, the EPC also validates the return privilege level (to ensure that it's no higher than the current executing privilege level) before it promotes.
added Jan. 2010: "SYSENTER: a good idea, taken too far..." [Andy Glew's description of x86 SYSENTER/SYSEXIT]
[History page] [Mark's homepage] [CPSC homepage] [Clemson Univ. homepage]