Hardware protection and privilege rings

Memory protection keeps one process’s memory apart from another’s. The CPU addresses memory with two registers together: a segment register, which identifies which segment of memory is meant, and an address register, which points to a location inside that segment. A process that tries to reach outside its own segment triggers a segmentation fault, SIGSEGV, on both reads and writes, and the operating system, not the process, decides what happens next.

Privilege rings layer the CPU’s own permissions the same way. Code runs in one of several rings, each a distinct privilege class, and the current privilege level can only be changed by code already running in ring 0. Ring 3 code, the outermost and least privileged, cannot reach ring 0 objects directly; it has to go through a gate, a controlled entry point that lets code run at a different privilege level under supervision, and the same mechanism manages supporting infrastructure such as multiple stack segments.

Two Intel chips set this up historically. The 80286 introduced segment addressing and protection rings in the first place. The 80386 added built-in virtual memory and expanded memory segments to 4GB.

Modern Intel CPUs carry this further than the classic four rings. There are actually nine rings: ring 0 to 3 for normal code, a second ring 0 to 3 underneath that for the hypervisor’s VMX root mode, and system management mode (SMM) at the bottom for the BIOS. In practice only four of the nine are used: SMM, ring 0 of VMX root mode, the ordinary ring 0 for the operating system kernel, and ring 3 above that for applications. Rings 1 and 2, in both sets, sit unused.

The lecture’s own diagram of this, Figure 2, credited to Wikipedia, did not survive PDF extraction. The diagram below is built from the same four levels the notes describe directly.

This is the same principle of least privilege the rest of the module keeps returning to: all code should run with the minimum privilege it needs, never more, and the number of paths into the kernel should be kept to the smallest set possible and tightly controlled. Rings are the hardware’s version of that rule. Less-privileged code, further from ring 0, cannot reach more-privileged code directly; every path in goes through a controlled gate instead.

ARM is the processor family in most phones, tablets and IoT devices. Unlike Intel, ARM licenses processor cores to other chip designers rather than building complete chips itself, so its hardware protection is far more customisable. Early ARM cores had no memory management built in at all. Current variants split into two tiers: a memory protection unit (MPU), which enforces fixed memory regions without virtual addressing, and a memory management unit (MMU), which adds full virtual memory on top.

ARM’s latest addition is CHERI (Capability Hardware Enhanced RISC Instructions), which brings fine-grained capability support to the architecture. A process spawning a subthread can hand it read and write access to a specific memory range, rather than the whole address space, so several sandboxes can run inside a single process. The lecture frames the payoff as a long-term promise rather than a shipped result: used thoroughly across an operating system like Windows, Android or iOS, CHERI has the potential to prevent most of the zero-day exploits seen in recent years, but that depends on adoption that has not happened yet.

Isolated cryptographic components take a different approach: instead of isolating code, they isolate the key itself. A cryptographic key stored in dedicated hardware never has to leave that hardware to be used; the surrounding system reaches it only through a restricted interface that performs authorised operations without ever exposing the raw key. The lecture’s example is the TPM (Trusted Platform Module), originally built for Digital Rights Management, which now provides that kind of isolated storage for cryptographic operations more broadly.