22C:18, Lecture 33, Fall 1996

Douglas W. Jones
University of Iowa Department of Computer Science

Privelege, Protection and Security

On a single-user machine, there is only a limited need for protection or security mechanisms. If the user runs a program and it fails destructively, that user is at fault and the same user is the only victim. This is how protection and security questions were addressed on the very first computers in the 1940's, it is how these questions were addressed on the first minicomputers of the 1960's and the first microcomputers of the 1980's.

With each generation of computers, we were forced to deal with the fact that our computers are rarely so personal that the only victim of a user's mistakes is that same user. Most of our machines are shared, either by many users at once, or by users in sequence. Because of this, users quite reasonably demand to be protected from the mistakes of other users and they demand security in the face of malicious users.

It is important to note that malice and carelessness are almost always equivalent threats to a system. What a malicious user may do intentionally, a careless user may do by accident. Some of the very first large scale computer network failures illustrate this quite well. On Nov. 3, 1988, Robert Tappan Morris, a grad student at Cornell, released a program known as the internet worm that reproduced without limit on various computers on the internet, bringing a good part of the network to a stop. (For fun, try searching the web for a history of the worm.) Morris's worm was released deliberately (although its effects were more severe than Morris expected because of a programming error).

In December 1987, a German user on BITNET sent out a Christmas greeting that was almost as effective as Morris's worm, but it did its damage entirely by accident. The greeting was a command script sent out as E-mail, and if a user chose to run the script, it output a picture of a Christmas tree and then automatically sent copies of itself to everyone the recipient had recently corresponded with. The developer of the Christmas Tree Exec, or the Christma Exec (truncated to 8 letters) as it is now known, only intended to spread a bit of "Christmas cheer," but the consequence was large-scale disruption of BITNET and a total shutdown of IBM's internal network. (For fun, try searching the web for a history of the Christma Exec.)

The distinction between security and protection is fundamental and important. We ask that our computers contain protection mechanisms, and we then ask that those mechanisms be used to implement security policies. A typical security policy will state who has what access to what resources. This policy can rest on any of a number of mechanisms ranging from armed guards to locked doors to passwords on computers.

The most fundamental thing a protection mechanism must protect is itself; otherwise, any user could crack the protection of the mechanism and subvert whatever policy the mechanism was designed to protect. Typical protection mechanism divide the world of programs into two classes, a privileged class and an unprivileged class. Privileged programs are entitled to perform any operations, while unprivileged programs are tightly restricted.

Note that the name privilege and is not universal. Depending on the system, other terms may be used:

        Privileged       |       Unprivileged
         Monitor         |
        Supervisor       |           User
          Kernel         |         Problem
          System         |
Thus, one system may be described as being either in system state or in user state, while another may be in either supervisor mode or in problem mode. (In this context, problem mode is not a problem, it merely indicates that the computer is working on some user's problem, as opposed to running privileged operating system code.)

Privelege on the Hawk

On the Hawk machine, as on most others, a field of the processor status word is reserved to indicate whether or not the current program is privileged. Specifically, the privilege of the current program is indicated by the high 4 bits of the PSW. If these bits are all 1, the program is not privileged; if any of them are zero, the program is privileged.

Why four bits and not one? Many CPU designs use only one bit for privilege, but these 4 bits have a second function, having to do with input/output interrupts. If all 4 bits are 1, all interrupts by external devices are allowed. Setting a bit or combination of bits to zero disables interrupts from one or more devices. Setting all bits to zero disables all interrupts from external devices. User programs may not disable interrupts, so this field of the PSW is safe to use for both controlling interrupts and for control of privilege.

What rights does privilege protect on the Hawk? In order to prevent misuse of privilege, the PSWSET instruction must be illegal in unprivileged mode, since if it were legal, unprivileged programs could arbitrarily grant themselves privilege whenever they wanted it. To simplify the hardware used to detect privilege violations, all instructions with the opcode 0xBx (hexadecimal, with x meaning don't care) are privileged. This includes the following:

	PSWSET  PSWGET
	TPCSET  TPCGET
	TMASET  TMAGET
	TSVSET  TSVGET
	CYCSET  CYCGET
	RTT
As well as 5 others. In the case of the PSW, user programs do not need to get or set the entire register, as special instructions are provided for manipulating any bits that matter to user programs. In the case of the TPC, TMA and TSV registers, user programs do not even need to know that these exist. The CYC register is useful for accurate performance measurement, but it is also dangerous to allow such measurements in certan secure system contexts.

Gate Crossing on the Hawk

What happens if a program attempts to execute a privileged instrucion when that program has no privilege? The hardware traps such attempts, turning control over to the monitor. The monitor, which is itself privileged, takes over control of the computer at this point. Thus, when a user program tries to execute a privileged instruction, it actually gets privilege! But, in the process, the program that was running loses control of the machine. The monitor may, of course, do whatever it wants, and this may include returning to the program.

Many authors have described the separation between unprivileged and privileged states as being defined by a fence. If the system is truly secure, this fence must be uncrossable except at well defined gateways. These gateways are the entry points of privileged routines, and the mechanisms that allow execution to pass through such a gateway are described as gate crossing mechanisms.

On the Hawk machine, there are only two primary gate crossing mechanisms, traps (and interrupts), used to gain privelege, and the RTT instruction, used to relinquish privilege and return to an unprivileged program.

In our earlier discussion of traps, we ignored privilege; now it is time to correct this oversight: When a trap (or interrupt) occurs, as discussed previously, the program counter PC is stored in the TPC register, and the PC is set to the appropriate address in the trap vector. In addition to this, the privilege level field of the PSW, LEVEL, is copied into the old-privilege level field, OLEVEL, and LEVEL is set to zero.

PSW FORMAT
 _______ _______ _______________ _______________ _______ _______
|_______|_______|_______________|_______________|_______|_|_|_|_|
| LEVEL | OLEVEL|               | DECIMAL CARRY |       |N Z V C|
The RTT instruction, which is itself privileged, undoes the state changes that occur with a trap. OLEVEL is copied to LEVEL and TPC is copied to PC. The trap service examples from the previous sections will all work correctly even if the user program is unprivleged!

But what does privilege protect? If privilege only exists to protect itself, it is not terribly interesting. The key is that privilege protects the right to access memory, as enforced by the memory management unit, and it protects the right to change the state of the memory management unit itself.

All of the resources that we want to protect from user programs, whether those programs are coded carelessly or maliciously, can be protected by the memory management unit. On the Hawk, input and output operations are performend by addressing certain parts of memory reserved for devices, and the memory management unit can make it impossible for a user program to change or even inspect memory belonging to the operating system or to other users.