Kernel space vs user space — why a crashing program doesn't crash the whole machine

Modern CPUs support at least two privilege levels. The kernel runs in the privileged one (kernel space), with full access to memory and hardware. Every ordinary program — your browser, your code editor, a script you wrote — runs in the restricted one (user space), which cannot directly touch hardware or another process's memory. This isn't just an operating system convention; it's enforced by the CPU hardware itself, which is exactly why user-space code genuinely cannot bypass it, even if it tries.

Because user-space processes can't directly touch each other's memory, one program crashing — dereferencing invalid memory, dividing by zero, hitting an unhandled exception — only affects that process's own memory space. The kernel (running in its separate, privileged space) simply cleans up the crashed process and reclaims its memory; every other running program is completely unaffected, since they were never sharing that memory to begin with.

This is also exactly why the previous lesson's system calls are the only door between the two worlds: a user-space program that wants the kernel to do something on its behalf has no way to just reach into kernel space directly — it has to go through the narrow, controlled system call interface, which is precisely what lets the kernel validate every request (permissions, valid arguments) before acting on it.

A system call is a controlled crossing of that boundary — a special CPU instruction temporarily switches the processor into kernel mode, the kernel performs the requested work with its full privileges, then switches back to user mode before returning control to your program. This switch has a real, measurable cost (it's not free), which is part of why reducing unnecessary system calls is a genuine performance concern in the same category as the CPU scheduling and context-switching overhead from earlier lessons.

"Why doesn't a crashed app take down my whole computer?" and "why can't a regular program just read another program's memory directly?" both have the same answer: the kernel/user space boundary is a hardware-enforced wall, not a polite convention any program could simply ignore. This is also the underlying reason a kernel-level bug (in a device driver, for instance) is so much more dangerous than an application bug — a crash inside kernel space genuinely can take the whole machine down, since there's no more privileged layer left to contain it.