Other meanings of Microkernel
Operating systems
Microkernel is an operating system kernel design with minimal core functionality: the privileged kernel retains only fundamental mechanisms such as address-space management, scheduling, interrupt handling, and interprocess communication, while drivers, file systems, networking, and other services run outside it. This separation aims to reduce the trusted computing base and contain failures, although communication and system organization can introduce performance and engineering costs.1
A microkernel keeps the privileged core small and moves most operating-system policy into separate user-space components. The kernel typically provides low-level mechanisms for threads, virtual memory, protection domains, interrupts, scheduling, and interprocess communication (IPC); a file system or device driver is instead implemented as a server that communicates through controlled messages.1
The distinction is architectural rather than a single fixed checklist: particular systems place different facilities in the kernel. The central contrast is with a monolithic kernel, where many drivers and subsystems execute in privileged mode. Microkernel designs therefore make explicit the boundaries between mechanism and policy, and between mutually isolated components. Their IPC path is especially significant because ordinary operating-system operations may require several protected cross-component exchanges.4
Microkernel research became prominent through systems such as Mach, Chorus, QNX, and the L4 family, each making different choices about IPC, memory management, device support, and compatibility. Mach influenced later operating-system research and was also used as a foundation for systems that placed substantial services outside the kernel.5 QNX developed the model for commercial real-time computing, where restartable user-space processes and predictable communication are valuable.3
Later work concentrated on reducing IPC overhead and making the kernel’s security properties precise. L4 pursued high-performance minimal kernels, while MINIX 3 placed drivers and other services in isolated processes. The seL4 project went further by formally verifying functional properties of a general-purpose microkernel, demonstrating that a small trusted base can be subjected to unusually rigorous mathematical analysis.4
The main benefit of a microkernel is that a failure in a user-space service need not corrupt the kernel or unrelated services. A faulty driver can potentially be stopped and restarted, and access rights can be narrowed by assigning components separate address spaces and explicit communication channels. This structure also supports portability, because hardware-specific code need not enlarge the privileged core.1
The costs are equally structural. IPC, context switches, copying or mapping message data, and coordination among servers can reduce performance when compared with direct calls inside a monolithic kernel. Developers must also design service protocols, recovery behavior, bootstrapping, and resource ownership across protection boundaries. Optimized IPC and carefully chosen kernel abstractions can narrow the speed difference, but they do not eliminate the additional complexity of distributing operating-system policy.4
Microkernel systems are not automatically secure, fast, or fault tolerant; those properties depend on the kernel mechanisms, server implementations, and configuration. A minimal kernel can still have a large trusted computing base if privileged components or mandatory system servers are included in the security argument. Conversely, formal verification can address specified properties without proving that every application or hardware device is safe.
A less visible application is the use of microkernel principles in embedded and safety-critical systems, where component restart, privilege separation, and analyzable behavior can matter more than peak throughput. Some systems also use hybrid arrangements: a small kernel hosts selected high-performance services in privileged mode while retaining user-space servers for other functions. MINIX 3 illustrates another niche concern by treating device drivers as replaceable processes, turning hardware support into a recoverable operating-system service rather than an inseparable kernel subsystem.2
Microkernel is an architectural category, not a single implementation; systems described as microkernels differ in the mechanisms they retain in privileged mode and in the services they delegate to user space.
Help improve the encyclopedia. Reports go straight to the site manager.