The kernel is the part of an operating system that runs with unrestricted access to the hardware. Every application and almost every service runs one privilege level down and has to ask the kernel for anything real: memory, a file, a packet, time on a core.
The processor enforces that boundary, which is why a user application crash kills the application and a kernel crash kills the machine. A third-party driver usually runs on the kernel side of the line.
- The kernel schedules processes, manages memory, and owns every device
- Applications reach it only through system calls, enforced by the CPU
- Kernel space is ring 0 on x86; user space programs run in ring 3
- Running as administrator is still ring 3, and is not kernel mode
- Most drivers run in kernel space, so a bad one is a crash, not an error
On this page
The jobsWhat the kernel actually does
Ask what is a kernel and most answers reach for the taxonomy, monolithic against microkernel, before saying what the thing does. It does four jobs, and every one of them exists because more than one thing wants the same hardware.
Scheduling. Deciding which user process gets a processor core and for how long. On a machine with eight cores and four hundred runnable threads, the illusion that everything is running at once is the scheduler doing several thousand context switches a second.
Memory management. Handing out memory, keeping each user process from reading another's, and maintaining the page tables that translate the addresses a program uses into the physical ones the hardware uses. When a program touches an address it has no right to, the hardware raises a fault and the kernel decides what happens next, which is usually killing the program.
Device access. Every disk, network card, keyboard and GPU is reached through the kernel and its drivers. This is the job that has grown the most and the one that causes the most trouble.
System calls. The interface everything else uses. Opening a file, sending a packet, creating a process and allocating memory are all requests across the boundary, not things a program does for itself.
Plenty of things people expect to find here are not part of the kernel at all, and the split is not always where intuition puts it.
| Component | In the kernel? |
|---|---|
| Process scheduler | Always |
| Memory manager and page tables | Always |
| Device drivers | Usually, and that is the problem |
| File systems | Yes on Linux and Windows, no on a microkernel |
| Network stack | Yes on Linux and Windows |
| The shell, and every command in it | No, ordinary user programs |
| The desktop and window manager | No, though Windows graphics is a partial exception |
| The package manager | No |
| The boot loader | No, it hands over and stops mattering |
The fourth and fifth rows are where the design argument lives, and the third is where the outages come from.
The boundaryKernel space and user space
The separation between kernel space and user space is not a convention that software agrees to observe. It is enforced by the processor.
x86 processors define four privilege levels, called rings, numbered 0 to 3. Practically every operating system, and every one of the kernels below, uses two of them. The kernel runs in kernel space, ring 0, where every instruction is legal and all memory is reachable. Everything else runs in user space, ring 3, where privileged instructions fault and memory outside the process is invisible.
Crossing from ring 3 to ring 0 happens only through a system call, which is an instruction that transfers control to an address the kernel chose in advance. A program cannot jump into the kernel at a place of its own choosing. That single restriction is what makes an operating system enforceable rather than advisory.
This is also the source of a persistent misunderstanding. Running a program as administrator or as root does not move it out of user space. It is still ring 3, still making system calls, still subject to the same hardware boundary. What changes is which requests the kernel is willing to grant. Administrator is a permission; ring 0 is a place.
The consequenceWhy a driver can take down the machine
Here is the part that matters operationally, and it follows directly from everything above.
A device driver has to touch hardware, and touching hardware requires ring 0. On Windows, Linux and macOS most drivers therefore load into kernel space, where they run with the same privileges as the kernel itself and inside the same address space.
There is no boundary between a driver and the operating system, because putting one there is exactly the cost the monolithic design chose not to pay.
So a driver that dereferences a null pointer is not a driver crashing. It is the kernel crashing, because at that moment the driver is the kernel. The operating system detects that its own state is no longer trustworthy and stops, because continuing means writing corrupt data to disk.
Windows calls this a bug check and shows a blue screen; Linux calls it a kernel panic. Both are the same decision: stop now, having done less damage.
That is also why kernel level software, from antivirus agents to anti-cheat systems to storage filter drivers, carries a risk out of proportion to what it does. Code in ring 0 has no containment. An update to it that would be a crashed process anywhere else is instead a machine that does not boot, on every machine that received the update.
The defensive measures follow. Windows requires kernel mode drivers to be signed. Both platforms have moved classes of driver into user space where the performance cost is acceptable, printer and some USB drivers among them, accepting slower reads and writes in exchange for containment.
And staged rollout matters more for anything that loads in ring 0 than for anything that does not, which is a patching policy question rather than a technical one.
The designsMonolithic, micro, and hybrid
The taxonomy is the part every explanation leads with. It is worth knowing and it decides less than it appears to.
Monolithic. Scheduling, memory management, file systems, networking and drivers all run in kernel space in one address space. Fast, because a call between these services is a function call rather than a message. Fragile in the way described above. Linux is monolithic, and so is Windows in every way that matters despite the label it prefers.
Microkernel. Only the minimal set of components runs in kernel space: scheduling, memory management, and inter-process communication, usually written IPC. File systems, drivers and networking run as ordinary user space services talking to each other over IPC. A driver crash kills a service the system can restart.
The cost is performance: a file read now crosses the boundary several times instead of once, and every IPC message is a boundary crossing. QNX and seL4 are real microkernels, and both are used in systems where reliability outranks throughput.
Hybrid. A monolithic kernel with some microkernel structure, so some services sit in user space and the performance sensitive ones do not. macOS and its XNU kernel are the usual example. In practice the label describes the source tree more than the runtime behavior.
Loadable modules complicate the picture. Linux is monolithic but loads most drivers as modules at runtime rather than compiling them in. That is a packaging decision, not an isolation one: a loaded module is in ring 0 in the same address space as everything else, so lsmod is a list of things that can panic the machine.
In practicePractical things that follow from having a kernel
A kernel update usually means a reboot. The running kernel cannot replace itself while it is running. Livepatching exists on Linux to apply certain security fixes without one, and it covers a subset of changes rather than all of them, so reboots do not go away.
Containers share the host kernel. That is the entire reason a container starts in a fraction of a second and a virtual machine does not: there is no second operating system to boot, only a user process on the kernel that is already running.
It is also the reason a container is a weaker isolation boundary than a virtual machine, because everything in the container is making system calls to the same kernel as everything outside it.
Version numbers matter more than they look. Driver and module compatibility is tied to the kernel version, which is why upgrading between Linux kernels can leave a third-party module unbuilt and a device gone. This is a patch scheduling problem before it is a driver problem. Check what is out of tree before upgrading, not after.
Kernel logs are a separate stream. dmesg on Linux and the System log on Windows carry messages from below the user application layer, and reading them is often the fastest way to find a failing device.
On a machine that is otherwise healthy, this is the layer to check before working back up through the network. When a machine misbehaves in a way no application log explains, this is where to look next.
PitfallsWhere people go wrong
Treating "run as administrator" as kernel access. It is not, and the distinction matters when reasoning about what a compromised process can actually do next. Escalating from ring 3 to ring 0 requires a vulnerability, not a permission.
Installing kernel level agents without staging them. Anything that loads in ring 0 deserves a slower rollout than anything that does not, because the failure mode is not an error message.
Reading a kernel panic as the cause. The panic is the machine noticing, not the thing that broke. The useful information is in the lines before it, and on Windows in the bug check code and the module named alongside it.
Assuming a container escape is hard because the container looks separate. It looks separate. It is one kernel, and every process inside is one system call away from it.
Upgrading the kernel and the out of tree modules separately. They are a matched pair. This is the most common way a working machine loses its network card during a routine update.
ComparisonMonolithic, micro and hybrid, on what each one costs
| Criterion | Monolithic | Microkernel | Hybrid |
|---|---|---|---|
| What runs in kernel space | Nearly everything | Scheduling, memory, IPC | Most services |
| Driver crash means | The machine stops | A user space service restarts | The machine stops |
| Speed of a file read | Function calls | Several IPC crossings | Function calls |
| Code in ring 0 | Millions of lines | Tens of thousands | Millions of lines |
| Used by | Linux, Windows | QNX, seL4 | macOS |
| Best at | Performance and hardware support | Reliability and isolation | Compromise |
The row that decides real deployments is the fifth. Monolithic kernels won the general purpose operating systems market because hardware support is a volume problem, and the design that lets thousands of vendors ship a driver is the design that gets thousands of drivers.
Microkernels win where a restart is unacceptable and the hardware is known in advance, which describes a car or a medical device rather than a laptop.
FAQFrequently asked questions
What is a kernel in an operating system?
The privileged core that owns the hardware. It schedules processes, manages memory, drives devices and exposes system calls, and it runs at a processor privilege level that ordinary programs cannot reach.
What does a kernel actually do?
Four things: decides which user process runs on which core, hands out and protects memory, provides access to every device through drivers, and answers system calls from every other component on the machine.
What is the difference between kernel space and user space?
Kernel space is ring 0, where all memory is reachable and every instruction is legal. User space is ring 3, where privileged instructions fault and a process sees only its own memory. Windows calls the same two states kernel mode and user mode. The processor enforces the split, and system calls are the only door.
Is running as administrator the same as kernel mode?
No. An administrator process is still in user space; the difference is which requests the kernel will grant it. Kernel mode is a processor state, not a permission level.
What is a kernel panic?
The kernel detecting that its own state is no longer trustworthy and stopping rather than continuing. Windows calls the same event a bug check and shows a stop error, commonly known as the blue screen.
Why does a bad driver crash the whole computer?
Because most drivers run in kernel space, in the same address space as the kernel, with the same privileges. A fault in a driver is a fault in the kernel, and there is no smaller thing to kill.
What is the difference between a monolithic kernel and a microkernel?
A monolithic kernel runs file systems, networking and drivers in kernel space for performance. A microkernel keeps only scheduling, memory management and IPC there and runs the rest as user space services, so a driver failure is recoverable and every operation costs more boundary crossings.
Is Linux a monolithic kernel?
Yes, with loadable modules. Loading a driver as a module is a packaging choice; the module still runs in kernel space in the same address space, so it can panic the machine exactly like built-in code.
Is Windows a microkernel?
No, whatever the historical marketing says. Its graphics, file system and driver services run in kernel space, which is the definition that matters when something crashes.
Why does a kernel update need a reboot?
Because the running kernel cannot replace itself in place. Linux livepatching applies some security fixes without a restart, but it covers a subset of changes, so scheduled reboots do not disappear.
Do containers have their own kernel?
No. Every container on a host shares that host kernel, which is why they start instantly and why the isolation is weaker than a virtual machine gives you.
How do I read what the kernel is saying?
dmesg or journalctl -k on Linux, and the System log in Event Viewer on Windows. These carry messages from below the application layer, which is where to look when no application log explains the behavior.
What kernel version am I running?
uname -r on Linux and macOS, winver or systeminfo on Windows. It matters most before installing anything that ships a kernel module, because compatibility is tied to that number.
Which is more secure, a microkernel or a monolithic kernel?
Microkernels have a far smaller trusted computing base, tens of thousands of lines of code rather than millions, and a compromised driver is a compromised process rather than a compromised machine.
That advantage is real and it is why microkernels are used in avionics and medical devices, and it is not enough to overcome the hardware support gap on general purpose computers.
Keep readingRelated concepts
Read next · Containers Containers vs VMs Containers share the host kernel, which is why they start instantly and why the isolation is thinner than it looks. Open this next11 min- Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching Anything that loads in ring 0 deserves a slower rollout than anything that does not, because the failure mode is not an error message.
- Platforms · 12 min Open Source Operating Systems, and Where the Cost Actually Goes Where the monolithic design and its loadable modules actually came from, and who maintains them.
- Operations · 13 min The Blue Screen Is a Decision, and It Leaves Evidence The reason there is no smaller thing to stop.