a protection ring
Imagine a target made of concentric circles, like a dartboard. The bullseye in the center is the most trusted, most powerful place; each ring outward is a step less trusted and less powerful. Hardware designers borrowed this picture to control what code is allowed to do. The CPU runs code at one of several privilege levels arranged as nested rings, with the innermost ring (numbered 0) the most privileged and the outer rings progressively restricted. This is the hardware foundation that makes the user-mode versus kernel-mode split real.
Concretely, the processor keeps track of the current ring in a small register, and certain instructions and certain memory or device accesses are flagged as requiring a minimum privilege. If code in an outer ring tries to execute a privileged instruction — say, one that disables interrupts or reprogms the memory-management unit — the hardware refuses and raises a trap, transferring control to a more trusted handler. Code cannot promote itself to an inner ring on a whim; the only way inward is through a controlled gate, such as a system-call instruction that jumps to a fixed, kernel-defined entry point. So the operating-system kernel runs in ring 0 with full power, ordinary applications run in the outermost ring (commonly ring 3 on x86) with their dangerous instructions disabled, and the hardware mechanically enforces the boundary on every instruction.
Rings matter because they are enforced by silicon, not by trust: a buggy or malicious application physically cannot run a privileged instruction, no matter how it tries. The honest reality is that, although classic architectures defined four rings (0 through 3), most real systems use only two of them — kernel in ring 0 and user in ring 3 — because two clean levels are enough and managing four added complexity for little gain. Virtualization later complicated the picture: a guest operating system expects to be in ring 0 but the hypervisor must really hold that power, which spurred extra hardware modes (sometimes loosely called ring -1) so a virtual machine monitor can sit beneath even the guest kernel.
An app calls read(fd, buf, n). The library issues a system-call instruction, the only legal gate inward; the CPU switches from ring 3 to ring 0 and jumps to the kernel's fixed entry point. The kernel does the privileged disk I/O, then returns, dropping back to ring 3. The app never executed a privileged instruction itself.
The only way from ring 3 to ring 0 is through a controlled gate, the system call.
Hardware may define four rings, but in practice almost everyone uses only ring 0 (kernel) and the outermost ring (user). The rings are enforced by the CPU itself, which is why an application cannot simply choose to run privileged code.