SciTech-Science-OS-Kernel: 可交互的Linux Kernel地图: Interactive Map of Linux Kernel

The GGPrompts

Links
https://ggprompts.com/architecture/linux-kernel/
https://ggprompts.com/architecture/index.html
https://github.com/GGPrompts/ggprompts
Sources:
Linux Kernel Architecture Map — built for GG Prompts
- https://ggprompts.com/architecture/linux-kernel/
- Data reflects kernel 6.x/7.x era (through 6.15).

Linux Kernel

The foundation of everything from smartphones to supercomputers — a monolithic kernel with modular capabilities powering over 90% of the world's infrastructure.

Created 1991
C + Rust (since 6.1)
GPLv2
Monolithic + Modules

Section 0: Summit View

The Linux kernel is the core of the GNU/Linux operating system.
Since Linus Torvalds' first release in 1991, it has grown into the most widely deployed OS kernel in history, running on everything from embedded IoT devices to the world's fastest supercomputers.

~40M Lines of Code
28,000+ Contributors
22 Architectures(Supported Hardwares)
7.x In Development(The Latest Version of Linux Kernel)
High-Level Layer Model
KPTI (Kernel Page Table Isolation):
the kernel maintains separate page tables for user and kernel space, Since Meltdown (2018)。
On syscall entry:
the CPU switches from the minimal user page tables,
to the full kernel page tables,
adding a small performance cost,
but closing the speculative execution side channel.
eBPF: the kernel's GPEM(General-Purpose Extension Mechanism)
BPF programs attach at socket filters, cgroup hooks, kprobes, tracepoints, and LSM hooks.
and at the Linux Network Stack, eBPF hooks span the entire stack Beyond XDP and tc.

Section 01: Kernel Layer Model

The kernel operates as topographic contours,
Understanding following elevation bands is key to navigating the codebase.

from the high-elevation userspace (Ring 3),
down through the syscall treeline,
into the lowland kernel subsystems (Ring 0),
finally reaching the hardware bedrock.

Fig 2.1 — Ring Model (Elevation Contours)

Section 2: Build System & Configuration

The KBS(kernel build system):
transforms a hierarchical configuration,
into a monolithic image plus optional loadable modules.

Kconfig manages ~20,000 options;
Kbuild orchestrates per-directory Makefiles.
Recent additions:
include Rust language support and Clang/LLVM as a first-class compiler.

Kconfig
Hierarchical configuration system.
- Interactive frontends: make menuconfig (ncurses), make xconfig (Qt).
- Output: .config file with CONFIG_* symbols.
- Supports: dependencies, selects, and choice groups.
Kbuild
Make-based build system with per-directory Makefiles using obj-y (built-in) and obj-m (module) syntax.
Handles header dependencies, cross-compilation, and incremental rebuilds.
Kernel Modules (.ko)
Loadable at runtime via modprobe/insmod.
DKMS rebuilds out-of-tree modules on kernel updates.
Module signing (CONFIG_MODULE_SIG) ensures only trusted modules load.
Rust Support: Available since 6.1, promoted to core language Dec 2025.
Requires LLVM/Clang toolchain.
bindgen generates Rust bindings from C headers.
First Rust drivers: Nova (GPU, 6.15), PHY, block.
- Since 6.1
Compiler Support
GCC (primary, widest arch support),
Clang/LLVM (required for Rust, CFI, and some sanitizers).
Cross-compilation supported for all 22 architectures via ARCH= and CROSS_COMPILE=.
Fig 9.1 — Build Pipeline

Module signing:
When CONFIG_MODULE_SIG_FORCE is enabled,
the kernel refuses to load any module without a valid signature.
This is critical for Secure Boot chains ,
and is the default on RHEL, Fedora, and Ubuntu kernels.

Section 03: Process Management

Process management is the heartbeat of the kernel.
- The scheduler decides which task runs on which CPU,
- namespaces provide isolation for containers,
- cgroups enforce resource limits.
- Linux 6.6 replaced the venerable CFS with the EEVDF scheduler for fairer latency distribution.
EEVDF Scheduler
EEVDF(Earliest Eligible Virtual Deadline First) — replaced CFS in kernel 6.6.
Provides better latency guarantees by assigning virtual deadlines to tasks based on their weight and requested time slice.
- Active (6.6+)
task_struct: The central process descriptor (~8KB)
Contains:
- PID, state, scheduling info,
- memory maps, file descriptors, signal handlers, credentials,
- pointers to parent/child/sibling tasks.
Namespaces (8 types)
Isolation primitives for containers:
mount, UTS, IPC, net, PID, user, cgroup, time.
Each namespace gives a process its own view of a global resource.
cgroups v2
Unified hierarchy for resource control.
Controllers: cpu, memory, io, pids, cpuset.
A single tree mounted at /sys/fs/cgroup replaces the fragmented v1 design.
sched_ext (6.12)
BPF-extensible scheduler class —
- allows loading custom scheduling policies as BPF programs at runtime,
- Enables rapid experimentation with scheduling algorithms,
- without recompiling the kernel.
- New (6.12+)

Section 04: Memory Management

The memory subsystem,
- maps virtual addresses to physical pages,
- manages page caches for file I/O,
- balances memory pressure across NUMA nodes.
It uses a layered allocator stack:
- the buddy system for physical pages,
- SLUB for kernel objects,
- the page cache to unify file and memory semantics.
Virtual Memory
4-level (or 5-level on modern x86_64) page tables,
translate virtual addresses to physical frames.
Each process gets its own mm_struct and page table hierarchy.
Buddy Allocator
Manages physical page frames in power-of-2 blocks (order 0-10).
Splits and coalesces buddies to minimize fragmentation.
Operates per-zone (DMA, Normal, HighMem).
SLUB Allocator
The default slab allocator for kernel objects.
Caches frequently allocated structures (task_struct, inode, dentry) in per-CPU freelists for fast allocation.
Page Cache
Shared with VFS —
caches file data in memory,
using a radix tree (XArray since 5.x).
Read-ahead prefetching and write-back policies are tunable per-BDI.
OOM Killer & THP
When memory is exhausted,
the OOM killer selects and terminates processes based on oom_score.
THP(Transparent Huge Pages) automatically promote 4K pages to 2M hugepages,
to reduce TLB misses.
Fig 4.1 — Memory Allocation Flow

NUMA Awareness:
On multi-socket systems,
the kernel tracks,
which NUMA node each page belongs to,
and tries to keep memory allocations local to the CPU accessing them.
The numactl tool and /proc/<pid>/numa_maps expose this topology.

Section 05: File Systems & VFS

VFS(The Virtual File System)
provides a uniform interface for all filesystems.
Through operation tables on four key objects — superblock, inode, dentry, and file —
any filesystem can plug into the kernel without userspace knowing the difference.
VFS Abstraction
Four operation tables: super_operations, inode_operations, dentry_operations, file_operations.
Every filesystem implements these to integrate with the kernel.
Disk Filesystems
ext4 (default, journaled),
btrfs (CoW, snapshots, RAID),
XFS (high-perf, large files),
F2FS (flash-optimized),
bcachefs (new in 6.7, CoW with caching).
Virtual Filesystems
sysfs (/sys — device model),
procfs (/proc — process info),
tmpfs (RAM-backed),
overlayfs (container image layers)
debugfs (kernel debug).
Block Layer & I/O Schedulers
The block layer mediates between filesystems and storage drivers.
Schedulers:
- BFQ (fairness),
- mq-deadline (latency),
- Kyber (fast SSDs),
- none (NVMe direct).
Fig 5.1 — VFS & Filesystem Tree

Section 06: Networking Stack

The Linux networking stack:
implements the full TCP/IP suite with extensive hooks for:
packet filtering, traffic shaping, and programmable packet processing via eBPF.
Its flexibility has made Linux the foundation for modern SDN(software-defined networking).
Socket API
BSD-compatible socket interface. Supports:
AF_INET (IPv4), AF_INET6 (IPv6),
AF_UNIX (local), AF_NETLINK (kernel comms), AF_XDP (fast path).
TCP/IP Stack
Full IPv4/IPv6 dual-stack. Congestion control algorithms:
CUBIC (default), BBR (Google, bandwidth-based), DCTCP (data centers).
Pluggable via setsockopt.
Netfilter / nftables
The packet filtering framework.
nftables(successor to iptables) provides a unified rule engine,
with sets, maps, and concatenations for firewalling and NAT.
eBPF / XDP
Programmable packet processing in the kernel.
XDP runs BPF programs at the driver level,before sk_buff allocation —
enabling line-rate packet filtering, load balancing, and DDoS mitigation.
- eBPF hooks span the entire stack Beyond XDP and tc
- Rapidly evolving
Fig 6.1 — Packet Flow (Ingress)

Section 07: Device Drivers & Hardware

Driver code constitutes roughly 60% of the kernel source.

The UDM(Unified Device Model (device, driver, bus),
provides a consistent registration and discovery framework.
Hardware Description comes from Device Tree (ARM/RISC-V) or ACPI (x86).
UDM(Unified Device Model)
Three core abstractions: struct device, struct device_driver, struct bus_type.
The bus matches devices to drivers;
probing initializes the hardware.
Bus Types
PCI/PCIe (GPUs, NICs, NVMe),
USB (peripherals),
I2C/SPI (sensors, embedded),
Platform (SoC-integrated devices with no discoverable bus).
Hardware Description
DT(Device Tree) — compiled .dtb blobs for ARM/RISC-V.
ACPI — firmware tables for x86 describing topology, power, and devices.
Both feed into the device model.
DMA & IOMMU
- DMA allows devices to read/write memory directly.
- The IOMMU (Intel VT-d, ARM SMMU):
  - translates device addresses,
  - enabling isolation for VMs,
  - protecting against DMA attacks.
Interrupt Handling
- Top half: Minimal ISR in interrupt context.
- Bottom half: Deferred work via:
  - softirq (network/block),
  - tasklet (legacy),
  - workqueue (process context, sleepable).
Fig 7.1 — Driver Registration & Discovery

Security note:
DMA-capable devices have unrestricted memory access without an IOMMU.
This is why IOMMU isolation is critical for VM pass-through (VFIO),
and why Thunderbolt security levels exist to gate external device DMA.

Section 08: Security Subsystems

Security in the Linux kernel is layered and modular.
The LSM(Linux Security Modules) framework,
provides ~250+ hooks woven throughout the kernel,
allowing multiple security policies to coexist.
Alongside LSM, capabilities, seccomp-bpf, and integrity subsystems,
form a defense-in-depth architecture.
LSM Framework
~250+ hooks at security-critical points (file access, socket ops, task creation).
- Exclusive LSMs:
  - SELinux (RHEL/Fedora),
  - AppArmor (Ubuntu/Debian),
  - Smack (Tizen),
  - TOMOYO.
- Stackable:
  Yama, LoadPin, SafeSetID, IPE, Landlock, BPF LSM.
POSIX Capabilities
Fine-grained privilege splitting instead of all-or-nothing root.
Key capabilities:
- CAP_NET_ADMIN (network config),
- CAP_SYS_ADMIN (catch-all admin),
- CAP_DAC_OVERRIDE (bypass file permissions),
- CAP_NET_RAW (raw sockets).
seccomp-bpf
Syscall filtering via BPF programs.
Restricts which syscalls a process can invoke.
Used by Chromium, Docker, Flatpak, and systemd services.
Actions: ALLOW, KILL, TRAP, ERRNO, LOG, NOTIFY(user-space decision).
Landlock LSM(Stackable)
UAS(Unprivileged Application Sandboxing) (since 5.13).
Programs restrict their own filesystem and network access without root.
Stackable — layers on top of SELinux/AppArmor.
- Since 5.13
BPF LSM
PSP(Programmable Security Policies) via eBPF (since 5.7).
Attach BPF programs to any LSM hook for:
custom MAC policies, audit logging,
or runtime security monitoring without kernel recompilation.
- Since 5.7
IMA / EVM
- IMA (Integrity Measurement Architecture):
  measures file hashes,
  extends TPM PCRs,
  enforces appraisal policies.
- EVM (Extended Verification Module):
  protects security xattrs with HMAC/digital signatures.
  Together they enable trusted boot and runtime integrity.
Fig 8.1 — Security Hook Chain

Exclusive vs Stackable:
Only one exclusive LSM (SELinux or AppArmor or Smack) can be the primary MAC provider.
Stackable LSMs (Yama, Landlock, BPF LSM, LoadPin, SafeSetID, IPE) layer on top, each adding restrictions.
The kernel boot parameter lsm= controls the order.

Section 10: Kernel Interconnection Map

A full subsystem-to-subsystem view of the Linux kernel,
showing how the major components connect from userspace applications down to hardware.

This map illustrates the kernel’s:
- Layered Architecture**,
- the Cross-Cutting role of eBPF**,
- security hooks.
Fig 10.1 — Full Subsystem Interconnection

Modernization Tracker

Interactive map of Linux kernel

可交互的Linux Kernel地图

By Constantine Shulyupin -May 15, 20092346

The Linux Kernel is one of the most complex open source projects.
There are a lot of books, however it is still a difficult subject to completely comprehend.
The Interactive map of Linux Kernel gives you a Top-Down View of the Kernel.
You can see most important layers, functionalities, modules, functions and calls.
You can zoom in and drag around to see details.
Each item on the map is a hypertext link to source code or documentation.

Interactive map of Linux kernel - GitHub Pages