Kernel structures

Monolithic, microkernel, modular, hybrid: how trusted code is packaged and how isolation trades off against performance.

Monolith, microkernel, modular, hybrid

Start here

If you are new, focus on one question: “If this component crashes, what else can it take down?” That is the practical meaning of fault isolation across kernel structures.

What do we mean by “kernel structure”? (theory)

Kernel structure describes how subsystems (scheduler, VM, VFS, drivers, IPC) are packaged into address spaces and trust boundaries. A monolithic kernel runs most of them in one privileged image for fast in-kernel calls. A microkernel keeps a tiny privileged core and pushes file systems, network stacks, and drivers toward user-space servers, paying IPC costs for stronger isolation. Real systems are often hybrids: monolith + loadable modules, or kernel fast paths + user-space helpers (FUSE, graphics stacks).

The trusted computing base (TCB) is the set of components you must believe are correct for security claims to hold, structure directly affects TCB size.

By the end of this page you should be able to

Contrast monolithic vs microkernel on isolation, IPC overhead, and local call cost.
Explain what a loadable kernel module is (and is not) on Linux.
Describe FUSE and what functionality moves to user space vs what stays in the kernel.
Argue one scenario where you would accept weaker isolation for performance.

Three common labels (icons are mnemonics only)

Names you will hear in interviews and papers.

Monolith + modules

Microkernel

Hybrid

Why this topic exists in OS courses

You cannot evaluate container security, driver quality, or hypervisor design without knowing what shares the kernel’s single address space. Performance tuning also depends on structure: inlined VFS paths and shared page-cache metadata are monolith advantages.

TL;DR

Kernel structure describes how drivers, filesystems, and IPC are packaged: monolithic kernels trade isolation for performance; microkernels push services user-side; real systems are hybrids with loadable modules and user-space helpers.

Structure is about engineering tradeoffs: fault isolation, performance, verification effort, and upgrade velocity. When you design embedded or cloud systems, you pick not only algorithms but which parts must stay in the TCB (trusted computing base).

Monolithic kernels trade isolation for throughput; microkernels push drivers to user space and pay IPC. Linux’s loadable modules blur the line, still one address space, so a buggy module is kernel-equivalent to a core bug. Understand failure blast radius when comparing designs.

Four structural patterns (theory cards)

Stylized roles, real OSes mix features.

Monolith

Single binary: scheduler, MM, FS, drivers share address space, fast calls, weaker fault isolation.

Microkernel

Minimal core runs IPC, scheduling, low-level mapping; servers implement FS/network in user mode.

Modular monolith

Runtime load/unload of `.ko` into kernel VA; symbol exports/versioning manage ABI drift.

Hybrid (practical)

User-space FUSE/graphics stacks with performance-critical paths still in kernel.

Comparison tables

Structural comparison (stylized)

Style	Isolation	IPC overhead	Example
Monolith + modules	Weaker in-kernel	Low (function calls)	Linux
Microkernel	Strong	Higher	seL4, Mach heritage
Hybrid	Mixed	Mixed	Windows, macOS XNU aspects

Design axis

Axis	Monolith	Microkernel
Local call cost	Function pointer	Message + schedule
Driver fault	Kernel panic risk	Restart user server
Evolution speed	Modules / eBPF	User servers independent

Tradeoffs in prose

Address space boundaries = trust boundaries

In a monolith, a bug in any driver can corrupt unrelated subsystems, testing and exploit mitigations (KASLR, CFI) compensate.

IPC cost dominates microkernel debates

Cross-address-space messages pay TLB flushes and marshalling; batching and capability-based passing mitigate costs.

Modules complicate symbol versioning

Exported kernel symbols must remain stable or modules break, distribution kernels carry ABI guarantees.

User-space file systems exist

FUSE trades performance for ease of development; the kernel still mediates security and page cache interactions.

Linux can load `.ko` modules dynamically, still one address space with full privileges, unlike user-space drivers.

Windows uses a hybrid model: executive/kernel + user-mode drivers for some classes (print spoolers, some filters).

seL4 proves formal properties about its microkernel API, rare in mainstream OS engineering but instructive.

Pitfalls

“Microkernel is always slower”: IPC batching and hardware fastpaths narrowed the gap; throughput vs isolation remains workload-specific.
Ignoring module trust: Unsigned/out-of-tree modules disable some hardening features on secure-boot systems.

Terms

IPC

Inter-process communication, messages, shared memory, capabilities in microkernel designs.

LKM

Loadable kernel module, extends a running monolithic kernel.

Unikernel

Single-address-space image with application + minimal OS linked, no userspace/kernel split as usual.

Interview

Why can a monolithic kernel still support FUSE?
What failure mode moves you toward exokernels or unikernels?
How does eBPF relate to extensibility without recompiling the monolith?

Interview angle

Explain why Linux stayed monolithic historically and how namespaces/cgroups approximate some microkernel benefits.

Why monoliths won performance

Same address space enables fast sharing of page cache metadata, direct function calls into VFS, and fewer context switches for common paths.

Debate prompt

Argue both sides: “Move the GPU driver to user space.” Consider latency, DMA, and security.

Terminal

lsmod | head

Self-check

1A Linux kernel module runs in…

2Microkernels emphasize…

3FUSE moves what to user space?