跳到主要内容

第 4 章 你好，内核——Linux 内核模块与内核架构基础

章节引子：特权与边界​

想象一个场景：你正坐在一台运行的 Linux 机器前，手里有一段刚刚写好的 C 语言代码。在用户空间，你可以随意编译、运行它，看着它在终端里输出一行“Hello, world”然后退出——如果它崩溃了，也没什么大不了的，顶多是当前进程被干掉，操作系统稳如泰山。

现在，我想让你把这段代码想象成一颗即将注入操作系统心脏的子弹。

这不是一个夸张的比喻。在 Linux 内核编程的世界里，代码一旦进入内核空间，就不再是一个被监管的进程，而是操作系统本身。它运行在最高特权级别，拥有访问整个物理内存、直接操纵硬件端口、甚至拦截系统调用的能力。在这里，没有保护机制会把你拉回来，一旦指针指错了地方，后果不是段错误，而是整个系统的死机或重启——这也就是为什么内核开发让人既兴奋又战栗的原因。

但传统的内核开发流程简直是反人类的：你想改一行驱动代码，就得重新配置整个内核树，花几个小时重新编译 bzImage，然后重启机器。这种“修改-编译-重启”的死循环，足以消磨掉所有的创造力。

有没有一种办法，既能让我们像写用户态程序那样灵活地加载和卸载代码，又能保留内核态的强大能力？

这正是本章我们要解决的核心问题。Linux 给出的答案叫做 LKM（Loadable Kernel Module，可加载内核模块） 框架。它打破了内核“静态巨石”的刻板印象，赋予了 Linux 动态扩展能力的灵魂。

在这一章里，我们将建立对内核架构的基本认知——理解那条划分用户与内核的“界线”究竟意味着什么。然后，我们会亲手写出第一个内核模块，看着它从简单的 .c 文件变成 .ko 二进制文件，被 insmod 命令射入内核内存，并在 dmesg 的日志中留下它的第一声啼哭。

这不仅是代码的编写，更是对操作系统底层逻辑的一次“物理接触”。

4.1 架构图景：用户空间与内核空间​

在开始写代码之前，我们需要先退一步，看清我们要进入的“领地”是什么样子的。

4.1.1 两个世界，两种特权​

现代处理器不仅仅是一个执行指令的计算器，它还是一名严格的门卫。它支持不同的 特权级别。

对于 x86 架构，这叫 Ring 0 到 Ring 3；对于 ARM，这叫 Exception Level 0 到 3。不管名字怎么变，核心思想只有一个：安全与隔离。

操作系统利用这些硬件特性，将虚拟地址空间划分为两个截然不同的区域：

  1. 用户空间：

    • 这是所有应用程序——你的浏览器、文本编辑器、数据库进程——生活的地方。
    • 它们运行在非特权模式。
    • 它们被严格限制：不能直接访问硬件，不能随意读写内存，只能通过特定的“门”请求服务。

  2. 内核空间：

    • 这是操作系统核心——内核、驱动、网络栈——居住的堡垒。
    • 它运行在最高特权模式。
    • 它是系统的主宰：可以访问所有内存，操纵所有硬件，执行任何 CPU 指令。

💡 代码之外的关键点

很多初学者会混淆 Root 用户 和 内核特权。

  • Root 是操作系统软件层面定义的一个“超级用户”， UID 为 0。
  • 内核特权 是 CPU 硬件层面的状态。

虽然通常 Root 用户的进程可以通过系统调用进入内核特权模式，但概念上，内核代码本身运行的权限比单纯“作为 Root 运行脚本”要高得多。当你在编写内核模块时，你的代码就拥有了这种生杀予夺的权力。

4.1.2 桥梁：系统调用​

既然用户空间和内核空间是隔离的，应用程序怎么请求内核干活呢？比如，一个程序怎么把“Hello, world” 显示到屏幕上？

它不能直接操作显卡。它必须敲门。

唯一的合法入口就是 系统调用。像 open(), read(), write(), fork() 这些 API，看起来像是普通的库函数，实际上它们都是一扇扇通往内核空间的门。当用户进程调用它们时，CPU 会从非特权模式切换到特权模式，跳转到内核中预先定义好的代码执行，完成后再返回用户空间。

这就是我们要遵循的规则：用户空间通过库 API 和系统调用与内核通信。

4.1.3 内核内部：单体内核与模块​

Linux 内核采用 单体内核 架构。这意味着内核的所有核心组件——调度器、内存管理、VFS、驱动、网络栈——都共享同一个内核地址空间。它们之间可以直接调用函数，效率极高。

虽然 Linux 是单体的，但它并不僵化。现代内核通过 LKM 框架，允许我们将一部分代码（主要是驱动和文件系统）编写成独立的模块，动态地插入或拔出这个巨大的地址空间。

4.2 动力学：为什么我们需要 LKM？​

回到我们最初的动机：为什么要有内核模块？

4.2.1 传统方式的痛点​

设想你需要为新买的网卡写一个驱动。

  • 旧办法：把驱动代码扔进内核源码树的 drivers/ 目录，修改 Kconfig，配置为 Y（内置），然后……重新编译整个内核，重启系统。
  • 代价：即使你只改了一行代码，这整个过程也可能需要半小时。开发效率极低。

4.2.2 LKM 的优雅​

LKM 框架提供了一种动态扩展机制。你可以把驱动代码编译成一个独立的 .ko（Kernel Object）文件。

  • 插入：使用工具将 .ko 加载到内核内存。代码瞬间成为内核的一部分，拥有完整的内核权限。
  • 卸载：如果不想要了，或者需要更新版本，直接把它从内存中移除，甚至不需要重启系统。

这种“即插即用”的能力，让 Linux 变得极其灵活。

  • 发行版友好：Ubuntu 不知道你的电脑具体用什么网卡，所以它把几千个驱动都编译成模块，等你插上硬件时再自动加载对应的那一个，而不是把内核镜像做得像皮球一样大。
  • 开发友好：我们可以 insmod -> rmmod -> 编辑 -> 重新编译 -> insmod，几秒钟一个迭代。

类比：

你可以把内核想象成一艘巨大的航母。

  • 传统内置代码 是船体本身，建造时就得焊死，改了要进船坞。
  • LKM 模块 是集装箱。我可以在海上航行时，随时吊装一个新的集装箱上去，或者扔掉一个旧的。虽然它一旦上船就属于船载货（在同一个地址空间），但它是模块化的。

4.3 实践第一课：编写 Hello World 内核模块​

理论够了，让我们开始造这个“集装箱”。

4.3.1 准备工作：工具与环境​

在开始之前，你需要确认两件事。这就像你要做饭，得先有锅和米。

  1. 工具链：编译器。 在现代发行版上通常已经装好了。如果没有： 
    sudo apt install gcc
  2. 内核头文件： 这是最关键的。因为内核模块要和内核亲密无间地接口，它必须使用和当前运行内核完全一致的数据结构定义和函数原型。 
    sudo apt install linux-headers-generic
    安装后，你会看到 /lib/modules/$(uname -r)/build 这个符号链接，它指向了安装好的头文件目录（通常在 /usr/src/linux-headers-...）。这就是我们编译模块时的“基石”。

⚠️ 踩坑预警

千万不要试图直接用 gcc 命令去编译内核模块 C 文件！ 内核模块的编译过程极其复杂，依赖内核构建系统。必须使用 Makefile 和 make 命令。我们稍后会详细解释为什么。

4.3.2 代码初体验：打破 main() 的执念​

最难的往往是第一行代码。让我们看看一个最简单的内核模块长什么样。这里没有 main() 函数。

文件：helloworld_lkm.c

#include <linux/init.h>
#include <linux/module.h>

/* 模块元数据：这些信息可以通过 modinfo 看到 */
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("LKP2E book:ch4: hello, world LKM");
MODULE_LICENSE("Dual MIT/GPL");
MODULE_VERSION("0.2");

/* 初始化入口点：当模块加载时执行 */
static int __init helloworld_lkm_init(void)
{
    printk(KERN_INFO "Hello, world\n");
    return 0; /* 返回 0 表示成功 */
}

/* 清理出口点：当模块卸载时执行 */
static void __exit helloworld_lkm_exit(void)
{
    printk(KERN_INFO "Goodbye, world!\n");
}

/* 注册我们的入口和出口函数 */
module_init(helloworld_lkm_init);
module_exit(helloworld_lkm_exit);

让我们逐行拆解这个“生物体”：

  1. 头文件：
    • <linux/init.h> 和 <linux/module.h> 是内核模块的基石。注意，这里没有 <stdio.h>，那是用户空间的东西。内核空间不使用标准 C 库。
  2. 模块元数据：
    • 那些以 MODULE_ 开头的宏，不仅仅是注释。它们会被嵌入到编译后的 .ko 文件中。用户可以用 modinfo ./helloworld_lkm.ko 命令读出这些信息。这在正式的产品开发中非常重要，用于管理版权和版本。
  3. 入口与出口：
    • 内核模块没有 main()。它是事件驱动的。
    • module_init(helloworld_lkm_init)：告诉内核，“当你加载我时，请执行这个函数”。
    • module_exit(helloworld_lkm_exit)：告诉内核，“当你卸载我时，请执行这个函数”。
  4. __init 和 __exit 宏：
    • 这是内核的优化魔法。
    • __init 告诉链接器：“把这个函数扔到一个特殊的初始化内存段（.init.text）里”。一旦初始化完成，内核就会把这些内存释放掉，腾出宝贵的 RAM。
    • __exit 同理，用于清理代码。对于内置模块（非 LKM），这个宏会被忽略，因为内置代码不会被卸载。

4.3.3 返回值的哲学：0/-E 约定​

注意看 helloworld_lkm_init 函数返回了 0。

这里有一个内核编程的铁律，和用户空间编程直觉相反：

  • 成功返回 0。
  • 失败返回负数错误码（如 -ENOMEM, -EINVAL）。

为什么？ 内核在这个初始化函数里，是在代表用户空间进程（调用 insmod 的那个进程）干活。根据 POSIX 系统调用的约定，如果失败，内核需要设置全局变量 errno。 内核通过返回负的错误码（如 -12，即 -ENOMEM），上层的系统调用封装（glibc）会把它取反变成正数（12），赋给 errno，并给用户空间返回 -1。

🚫 踩坑现场

如果你写了一个 init 函数，最后忘了写 return 0;，或者返回了一个正数（比如 1），在某些旧内核上，你的模块会被立即拒绝加载；在新内核上，你会收到一个警告，且模块可能无法正常工作。 结论： 成功一定要显式返回 0。

4.4 构建系统：Makefile 中的魔法​

代码写好了，怎么把它变成 .ko？我们需要一个特殊的配方。

文件：Makefile

# 获取当前目录路径
PWD := $(shell pwd)

# 指向内核构建目录（这是关键！）
KDIR := /lib/modules/$(shell uname -r)/build/

# 核心目标：告诉 Kbuild 我们要编译哪个模块
# obj-m 表示“编译成模块”
obj-m += helloworld_lkm.o

# 默认目标：编译模块
all:
	make -C $(KDIR) M=$(PWD) modules

# 清理目标
clean:
	make -C $(KDIR) M=$(PWD) clean

这里的 make -C $(KDIR) M=$(PWD) modules 到底发生了什么？ 这句命令非常精妙，它是 LKM 构建的核心：

  1. make -C $(KDIR)： 我们并没有在当前目录运行 make，而是把控制权移交给了 内核源码树的顶层 Makefile（位于 /lib/modules/.../build，也就是那个 linux-headers 目录）。这是为了保证我们的模块是严格按照当前内核的配置、编译器 flags 和宏定义来构建的。

  2. M=$(PWD)： 这是一个参数。我们告诉内核的 Makefile：“嘿，老大，虽然你住在 /usr/src/...，但我要让你回过头来编译 我当前这个目录 里的模块。”

  3. modules： 这是内核构建系统的目标，告诉它我们要构建的是模块。

变量 obj-m： 这是 Kbuild 系统的语法。

  • obj-y：如果你写的是 obj-y += foo.o，意味着 foo.c 会被编译并链接进 静态内核镜像（vmlinux）。
  • obj-m：如果你写的是 obj-m += foo.o，意味着生成 可加载模块 foo.ko。

现在，运行构建命令：

make

如果一切顺利，你会看到编译输出，并在当前目录下生成一个名为 helloworld_lkm.ko 的文件。这就是我们要注入内核的“集装箱”。

4.5 生命周期：加载、运行与卸载​

现在，手握 .ko 文件，我们要开始动手了。

4.5.1 注入内核：insmod​

我们使用 insmod 命令将模块插入内核。

$ sudo insmod ./helloworld_lkm.ko

这里发生了什么？

  1. insmod 是一个用户空间工具。
  2. 它读取 .ko 文件内容。
  3. 它发起系统调用（finit_module 或旧版的 init_module）。
  4. 内核接管，将代码段和数据段加载到内核内存，解析符号，执行你的 helloworld_lkm_init 函数。

4.5.2 看不见的输出：printk 与 dmesg​

代码跑了吗？让我们看看日志。 在内核里，我们不能用 printf。内核没有 C 库。它有自己的打印函数：printk。 printk 会把消息写入 内核日志缓冲区。

要查看这个缓冲区，我们使用 dmesg 工具：

$ sudo dmesg | tail -n 5
[ 4123.028252] Hello, world

⚠️ 权限问题

在 Ubuntu 等发行版上，普通用户运行 dmesg 可能会报错： dmesg: read kernel buffer failed: Operation not permitted 这是因为 dmesg_restrict 安全机制开启，防止普通用户窥探内核细节。请务必使用 sudo。

💡 关于 "Tainted Kernel"

在日志中，你可能会看到一行警告： kernel: loading out-of-tree module taints kernel. 别慌！ 这只是一个“污染”标记。因为你加载了一个非官方内核树里的（out-of-tree）未签名模块，内核开发者想表达：“如果现在系统炸了，别怪我们，因为我们不知道这个模块干了什么。” 对于学习和开发，这完全没问题。

4.5.3 检查存活状态：lsmod​

你的模块现在正作为一个内核实体活着。我们可以用 lsmod 命令查看所有驻留内存的模块。

$ lsmod | grep helloworld
helloworld_lkm         16384  0

输出包含三列：

  1. 模块名
  2. 内存大小（字节）
  3. 引用计数（0 表示没有被其他模块依赖，可以安全卸载）

4.5.4 退出舞台：rmmod​

当戏演完了，我们把它卸载。

$ sudo rmmod helloworld_lkm

此时，内核会调用你编写的 helloworld_lkm_exit 函数。 让我们再次验证一下：

$ sudo dmesg | tail -n 5
[ 4123.028252] Hello, world
[ 40280.138269] Goodbye, world!

看到了吗？“Goodbye, world!” 出现了。你的模块优雅地离开了内存。

4.6 深度潜入：内核日志与 printk 的高级用法​

你现在已经会写最简单的模块了，但 printk 这个“控制台输出”其实是个深海怪兽，远比看起来复杂。

4.6.1 日志级别：KERN_INFO 是什么？​

回顾代码：

printk(KERN_INFO "Hello, world\n");

注意 KERN_INFO 前面 没有逗号。这不是参数，而是字符串拼接。在预处理阶段，它会变成一个特殊的 ASCII 字符（Start of Header, \001）加上数字 "6"。

内核定义了 8 个日志级别（0-7）：

  • KERN_EMERG "0"：系统不可用（快炸了）。
  • KERN_ALERT "1"：必须立即采取措施。
  • KERN_CRIT "2"：严重情况。
  • KERN_ERR "3"：错误。
  • KERN_WARNING "4"：警告。
  • KERN_NOTICE "5"：正常但重要。
  • KERN_INFO "6"： informational。
  • KERN_DEBUG "7"：调试信息。

这个级别有什么用？ 控制台输出控制。 内核有一个参数叫 console_loglevel（在 /proc/sys/kernel/printk 里）。只有日志级别数字 小于 这个级别的消息，才会被打印到当前的控制台终端（也就是你看到的屏幕）。

  • 如果级别设为 4，那么 KERN_ERR (3) 会打印，但 KERN_INFO (6) 不会打印到屏幕，只会存在缓冲区里，等你用 dmesg 去看。
  • 如果你想让所有消息都像 printf 一样直接刷屏，可以（临时）把级别改成 8： 
    sudo sh -c "echo '8 4 1 7' > /proc/sys/kernel/printk"

4.6.2 现代写法：pr_info 系列​

虽然你可以一直用 printk(KERN_INFO "msg")，但内核开发者推荐使用更现代、更方便的宏封装：

pr_info("Hello, world\n");
pr_err("Something went wrong: %d\n", err);

这些宏本质上还是 printk，但它们自动处理了日志级别字符串，并且配合 pr_fmt 宏使用时非常强大。

标准化你的输出： 你可以在文件最开头定义 pr_fmt，这样这个文件里所有的 pr_xxx 都会自动带上前缀（比如模块名）。

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

#include <linux/module.h>

// ...
pr_info("Data loaded\n"); // 实际输出: "helloworld_lkm: Data loaded"

4.6.3 动态调试：Dyndbg​

如果你觉得 #ifdef DEBUG 太土，内核还有一个神器叫 Dynamic Debug。 当你在内核配置里开启了 CONFIG_DYNAMIC_DEBUG，你可以通过 debugfs 在 运行时 开关任意一个 pr_debug() 调用语句，甚至按文件名、函数名匹配。

比如，让 usb 核心代码里的所有调试信息都打印出来：

echo 'file *usb* +p' > /sys/kernel/debug/dynamic_debug/control

这比重新编译模块不知道高到哪里去了。

4.6.4 速率限制​

如果你在一个高频率执行路径（比如每秒触发 1000 次的中断处理函数）里写了 printk，你的控制台会被刷爆，日志会被冲刷，甚至可能导致系统卡顿。

内核提供了 Rate-Limited 版本的打印宏：

pr_info_ratelimited("High frequency event: %d\n", val);

这会自动限制打印频率（默认是每 5 秒允许一次突发），并在日志里告诉你“ suppressed N callbacks”，让你知道发生了多少次但没打印出来。

本章回响​

还记得我们在本章开头提到的那个问题吗：如何在保持内核稳定的前提下，动态地赋予它新的能力？

现在你已经有了答案。 LKM 框架并不只是一个“加载驱动”的工具，它是 Linux 内核模块化哲学的物理体现。通过 insmod，我们将代码注入内核的高特权地址空间；通过 module_init，我们在内核的呼吸间插入了初始化逻辑；通过 printk，我们建立了一条从内核深处通往人类眼球的沟通管道。

我们这一章表面上是在写 Hello, world，实际上是在学习如何在规则最森严的禁区里安全地行走。你学会了为什么不能用 printf，为什么返回值是负数，为什么 Makefile 要借用内核的构建系统。

下一章，我们将深入这片领地，处理更复杂的情况——模块间的依赖、参数传递、以及如何在内核和用户空间之间传递真正的数据，而不仅仅是打印一串字符。

那时候，你会发现，今天建立的所有认知，都会以意想不到的方式再次派上用场。

练习题​

练习 1：understanding​

题目：判断题：用户空间的应用程序（如 Web 浏览器）可以通过直接访问内核空间的内存地址来调用内核功能，只要它知道正确的内存地址即可。

答案与解析

答案：错误

解析：用户空间和内核空间是隔离的虚拟地址空间。用户模式下的程序是非特权的，无法直接访问内核空间。所有对内核功能的请求必须通过系统调用这一合法入口点完成，系统调用负责执行从用户模式到内核模式的切换。直接访问内核内存会导致非法内存访问异常。

练习 2：application​

题目：在编写内核模块的初始化函数 static int __init my_init(void) 时，如果资源分配失败，按照内核编程的 0/-E 返回约定，函数应该返回什么值？

答案与解析

答案：负数错误码 (如 -ENOMEM 或 -1)

解析：在内核编程约定中，函数成功必须返回 0。如果发生错误（如内存不足、无法获取锁等），必须返回一个负数的错误码（例如 -ENOMEM 表示内存不足，-EINVAL 表示无效参数）。返回非零正值是违反惯例的行为，会导致系统误判为成功。

练习 3：application​

题目：场景应用：你正在为一个高频中断处理程序编写内核模块代码。该代码路径每秒可能被调用数千次，且包含一条 printk() 日志输出语句。为了防止这条日志导致系统日志溢出或磁盘 I/O 过载，你应该使用哪种宏来替代标准的 printk()？

答案与解析

答案：pr_info_ratelimited() 或 printk_ratelimited()

解析：标准 printk 在高频调用下会产生“日志风暴”。内核提供了速率限制机制，通过 pr_<foo>_ratelimited() 系列宏（如 pr_info_ratelimited），可以确保同一条日志消息在特定时间窗口内只输出一次，从而保护系统稳定性。

练习 4：thinking​

题目：思考题：为什么内核模块（LKM）不能像用户空间程序那样简单地链接使用标准 C 库（glibc）中的 printf() 函数，而必须使用内核特有的 printk()？这背后反映了操作系统设计中关于“上下文”和“依赖”的什么本质区别？

答案与解析

答案：主要因为运行环境（上下文）和依赖库的不同。内核运行在独立的地址空间且缺乏用户空间库的支持。

解析：这个问题的核心在于理解内核与用户空间的本质差异：

  1. 上下文环境：内核模块运行在内核空间，拥有最高的特权级（Ring 0），直接管理硬件，没有运行时环境支撑。
  2. 库依赖：glibc 是运行在用户空间的库，它依赖内核提供的系统调用来工作（实际上 glibc 的 printf 最终也会调用 write 系统调用）。内核处于底层，无法“依赖”上层库，否则会造成循环依赖。
  3. 功能差异：printf 需要格式化缓冲区、处理流 I/O，而内核需要更底层的、不依赖复杂缓冲区机制且能安全在中断上下文中运行的日志工具，即 printk。 这反映了操作系统的分层设计原则：底层模块不能依赖上层实现，必须自包含。

要点提炼​

Linux 内核通过特权级别将虚拟地址空间严格划分为用户空间与内核空间。前者运行应用程序受限于非特权模式，只能通过系统调用请求服务；后者则是操作系统核心运行的最高特权模式，拥有访问所有内存和硬件的权限。理解这一边界是内核开发的前提，因为内核模块代码一旦加载将在此无保护的高权限环境中直接运行。

为了解决传统内核开发“修改-编译-重启”的低效死循环，Linux 引入了可加载内核模块（LKM）机制。LKM 允许将驱动或功能代码编译成独立的 .ko 文件，通过 insmod 和 rmmod 命令动态地插入或卸载，无需重启系统即可扩展内核功能。这种机制让 Linux 单体内核在保持高性能的同时，获得了类似微内核的灵活性。

内核模块没有用户态程序中的 main 函数，而是基于事件驱动模型，通过 module_init 和 module_exit 宏指定初始化与清理函数。初始化函数必须返回 0 表示成功（失败则返回负错误码），且编译时使用 __init 宏可以将代码放入临时内存段以节省 RAM。这种设计明确了模块的生命周期管理，与内核的构建流程深度绑定。

构建内核模块不能使用标准的 gcc 命令，必须依赖内核自带的 Kbuild 构建系统。在 Makefile 中，需定义 obj-m 变量指明目标模块，并通过 make -C $(KDIR) M=$(PWD) 命令借用当前内核源码树的配置和头文件进行编译。这确保了模块能与当前运行的内核版本严格匹配，避免因接口不一致导致系统崩溃。

内核空间无法使用标准 C 库函数，因此 printf 被替换为 printk，后者将日志输出到内核缓冲区而非终端。通过 dmesg 工具可以读取这些日志，而日志级别（如 KERN_INFO）则决定了消息在控制台的显示策略。熟练使用 printk（或现代的 pr_info）及其日志级别，是开发者从内核内部获取调试信息的关键手段。

编辑此页
最后由 Charliechen114514 于 更新