Processor Privilege

On path: OS Topics	1: Concepts • 2: Cache • 3: Context • 4: Processor Privilege • 5: Process Scheduling • 6: Exceptions • 7: Interrupts • 8: Direct Memory Access (DMA) • 9: Virtualisation • 10: Hypervisor

Depends on	Security

Privilege Levels

To facilitate protection in an operating system a processor may support different privilege levels. For example, a simple, two-level model will have “user” and “supervisor” modes.

In supervisor mode the processor can do ‘anything’.
In user mode, some actions are forbidden – including altering the mode!

The mode is visible to the hardware which can use this information to decide whether to allow an action to take place. It is arguably this distinction of privilege which determines if something is part of the OS kernel.

Example: There will be I/O devices which interact with the outside world; these need careful handling and should not be used directly by applications. A reference to such a device can be detected and only allowed if the processor is currently in supervisor mode. Attempts to get at these devices by users may result in a ‘privilege violation’, preventing the action and, maybe, stopping that process although the overall computer operation can continue.

Because privilege is monitored in hardware it does not normally impinge on application execution. There is no performance penalty unless/until the user needs an OS service or misbehaves in some way.

The privilege required for a given action may be specified in a number of ways.

Access to memory may have programmable privilege which is set by (e.g.) entries in page tables in a virtual memory system.
- The memory containing the page tables would normally also be protected.
Access to some devices may require privilege and be set when the machine (usually a single chip, these days) was built. The Memory Management Unit (MMU) would be one such example.
Altering the interrupt status (to allow more/fewer interrupts) is a privileged operation. Interrupt service routines are part of the OS code and users should not be able to turn them on and off.
Changing the privilege level itself is restricted so it cannot be increased (except in specific, well-controlled ways). Thus a user cannot promote himself.

Switching into supervisor mode is only possible under certain, controlled circumstances (exceptions) where it can be guaranteed that trusted code is run. These operating system entry points include:

Getting out of supervisor mode is (in principle) easy although in practice this is still ‘trusted code’.

Used correctly, the privilege level can allow applications to run freely – as long as they behave – but stop them from affecting other processes or crashing the system. This is a security measure, protecting against both crashes and malicious hacking.

Privilege switching

A point to note is that (at the processor level) the switch both in and out of the O.S. has to be atomic: i.e. a single instruction or similar operation. This sometimes requires the use of specialist operations such as “return from interrupt”; a modern compiler might sort this out for you automatically.

Take the case of leaving the O.S.

If the code first branched back to the user then this assumes the user code would relinquish the privilege: a dangerous security hole.
If the code first switched out of privileged mode the next instruction fetch (in user mode, from O.S. space) would violate the privilege level and cause another exception.

Switches therefore have to be, effectively, simultaneous. Processors have to support this.

Other privilege modes

Separating operation into user and supervisor modes provides most of the protection needed under ordinary circumstances. However it is sometimes extended further. For example, some ARM processors contain a “TrustZone^®” mode bit, which allows trusted access to certain resources by some user-mode applications.

More generally, as computers (and users) grow more sophisticated there is a demand for virtualisation of the operating system itself, enabling (say) the same machine to be running Linux and Windows simultaneously. The difficulty is that each operating system believes it has sole control of the machine’s hardware. This can be detected and trapped by the addition of a further “hypervisor” mode with its accompanying software.

The privilege level of the processor is similar in principle to the concept of a ‘superuser’ (a.k.a. “root” or “admin”) in system management. However it is not the same thing; it is an operation mode maintained by the processor and may tested for every instruction executed.