Rethinking Linux Kernel Modularity: Microkernel with Tiered Modules (C Core + Rust Layers)

xunileht

Fellow Linux kernel developers and enthusiasts,
In recent years, there's been growing interest in integrating memory-safe languages like Rust into the Linux kernel ecosystem. As of 2025, Rust code is landing at an increasing rate, with real implementations now reaching core system drivers for better memory safety and reliability. However, the current monolithic architecture still poses challenges: code bloat, debugging complexity, and vulnerabilities—not just from external attacks, but from internal errors like buffer overflows or data races, which are often overlooked in overall system security assessments.
I'd like to discuss a concept for a C-based microkernel for Linux with a strictly structured multi-level modular architecture. The core idea is to concentrate the essential kernel logic—such as memory management, basic IPC, and minimal syscalls—within the microkernel itself, keeping it lightweight and immutable. Extensions (drivers, subsystems) would then plug in via abstract interfaces, preserving the kernel's "purity," minimizing its footprint, and enabling easy swapping or removal of modules without recompiling the entire stack.
Proposed Level Structure:

Level 0: Microkernel in C
Houses the concentrated core kernel logic: memory management, basic IPC, and a minimal set of syscalls. This is the system's "heart," written purely in C for compatibility and performance. It enforces strict component isolation, drawing inspiration from microkernels like seL4 or Minix, but tailored to the Linux ecosystem.
Level 1: Interface Modules in C
Abstract "bridges" for external interactions. These define APIs for drivers (e.g., networking, block, or graphics devices), ensuring type safety and boundary checks. They remain part of the microkernel but are kept minimal—focused on contracts and input/output validation.
Level 2: High-Level Modules (Drivers and Subsystems)
Here, Rust could shine for memory safety, or even other languages (e.g., constrained Go or DSLs). Modules compile as dynamically loadable (LKM) or statically linked components, interfacing strictly with Level 1. Benefit: If a Rust module proves unstable or outdated, it can be discarded without touching the microkernel.
Level 3: Optional Extensions (for Specialized Systems)
For performance-oriented configs—direct assembly or C++ tweaks. For security-focused ones (e.g., embedded or cloud)—added verification layers with formal methods.

Benefits of This Architecture:

Purity and Modularity: The kernel avoids "clutter" from heterogeneous code. The core stays stable, while experiments (including Rust drivers) are isolated. Recent Rust integrations, like bindings crates for safe C interfacing, align well with this.
Flexibility for Scenarios: High-performance systems (servers, HPC) minimize levels to cut overhead. Secure setups (IoT, fintech) emphasize isolation and auditing.
Addressing Internal Threats: Unlike the current focus on external attacks (SELinux, AppArmor), this model treats internal errors as security risks. Rust at Level 2 could prevent common C pitfalls, while Level 1 interfaces catch mismatches early—especially timely amid ongoing Rust adoption debates.