如何解决Linux内核调测两大难题：内存被改与内存泄露_开源_Kernel SIG成员

【AICon】AI 基础设施、LLM运维、大模型训练与推理，一场会议，全方位涵盖！ >>> 了解详情 



 写点什么

1.背景

一直以来，内核内存调测领域一直持续存在着两大行业难题: "内存被改" 和 "内存泄漏"。内存问题行踪诡异、飘忽不定，在 Linux 内核的调测问题中，是最让开发者头疼的 bug 之一，因为内存问题往往发生故障的现场已经是第 N 现场了，尤其是在生产环境上出现，截止目前并没有一个很有效的方案能够进行精准的线上 debug，导致难以排查、耗时耗力。

接下来让我们来分别看一下"内存被改" 和 "内存泄漏"这两大难题为什么难。

1.1 内存被改

Linux 的用户态的每个进程都单独拥有自己的虚拟内存空间，由 TLB 页表负责映射管理，从而实现进程间互不干扰的隔离性。然而，在内核态中，所有内核程序共用同一片内核地址空间，这就导致内核程序在分配和使用内存时必须小心翼翼。

出于性能考虑，内核中绝大多数的内存分配行为都是直接在线性映射区划出一块内存归自己使用，并且对于分配后具体的使用行为没有监控和约束。线性映射区的地址只是对真实物理地址做了一个线性偏移，几乎可以视同直接操作物理地址，并且在内核态是完全开放共享的。

这意味着如果内核程序的行为不规范，将可能污染到其他区域的内存。这会引起许多问题，严重的情况下直接会导致宕机。

一个典型的场景例子：现在我们假设用户 A 向内存分配系统申请到了 0x00 到 0x0f 这块地址，但这只是口头上的“君子协定”，A 不必强制遵守。由于程序缺陷，A 向隔壁的 0x10 写入了数据，而 0x10 是用户 B 的地盘。当 B 试图读取自己地盘上的数据的时候，就读到了错误的数据。如果这里原本存着数值，就会出现计算错误从而引起各种不可预估的后果，如果这里原本是个指针，那整个内核就可能直接宕机了。

上述的例子被称为越界访问(out-of-bound)，即用户 A 访问了本不属于 A 的地址。内存被改的其他情况还有释放后使用(use-after-free)、无效释放(invalid-free)等。这些情况就想成 A 释放了这片空间后，内核认为这片已经空闲了从而分配给 B 用，然后 A 又杀了个回马枪。

例如，我们可以通过以下的模块代码模拟各种内存修改的例子：

//out-of-boundchar *s = kmalloc(8, GFP_KERNEL);s[8] = '1';kfree(s);
//use-after-freechar *s = kmalloc(8, GFP_KERNEL);kfree(s);s[0] = '1';
//double-freechar *s = kmalloc(8, GFP_KERNEL);kfree(s);kfree(s);

复制代码

1.1.1 为什么调测难

在上面的例子中，宕机最后将会由用户 B 引发，从而产生的各种日志记录和 vmcore 都会把矛头指向 B。也就是说，宕机时已经是问题的第二现场了，距离内存被改的第一现场存在时间差，此时 A 可能早已销声匿迹。这时内核开发者排查了半天，认为 B 不应该出现这个错误，也不知道为什么 B 的那片内存会变成意料之外的值，就会怀疑是内存被其他人改了，但是寻找这个“其他人”的工作是很艰难的。

如果运气好，宕机现场还能找出线索（例如犯人还呆在旁边，或是犯人写入的值很有特征），又或者发生了多次相似宕机从而找到关联等等。但是，也存在运气不好时没有线索（例如犯人已经释放内存消失了），甚至主动复现都困难的情况（例如隔壁没人，修改了无关紧要的数据，或者修改完被正主覆写了等等）。

1.1.2 现有方案的局限性

Linux 社区为了调试内存被改的问题，先后引入了 SLUB DEBUG、KASAN、KFENCE 等解决方案。

但这些方案都存在不少局限性：

SLUB DEBUG 需要传入 boot cmdline 后重启，也影响不小的 slab 性能，并且只能针对 slab 场景；
KASAN 功能强大，同时也引入了较大的性能开销，因此不适用于线上环境；后续推出的 tag-based 方案能缓解开销，但依赖于 Arm64 的硬件特性，因此不具备通用性；
KFENCE 相对来讲进步不少，可在生产环境常态化开启，但它是以采样的方式极小概率地发现问题，需要大规模集群开启来提升概率。而且只能探测 slab 相关的内存被改问题。

1.2 内存泄漏

相对内存被改，内存泄漏的影响显得更为“温和”一些，它会慢慢蚕食系统的内存。与大家所熟知的内存泄漏一样，这是由于程序只分配内存而忘记释放引起的。

例如，以下模块代码可以模拟内存泄漏：

char *s;for (;;) {    s = kmalloc(8, GFP_KERNEL);    ssleep(1);}

复制代码

1.2.1 为什么调测难

由于用户态程序有自己的独立地址空间管理，问题可能还算好定位（至少一开 top 能看见哪个进程吃了一堆内存）；而内核态的内存搅在一起，使得问题根源难以排查。开发者可能只能通过系统统计信息观察到某一种内存类型(slab/page)的占用在增长，却找不到具体是谁一直在分配内存而不释放。这是因为内核对于线性映射区的分配是不做记录的，也无从得知每块内存的主人是谁。

1.2.2 现有方案的局限性

Linux 社区在内核中引入了 kmemleak 机制，定期扫描检查内存中的值，是否存在指向已分配区域的指针。

kmemleak 这种方法不够严谨，也不能部署于线上环境，并且存在不少 false-positive 问题，因此定位不太精确。

另外，在用户态，阿里云自研运维工具集 sysAK 中也包含针对内存泄漏的探测。它通过动态采集分配/释放的行为，结合内存相似性检测，在某些场景下可以实现生产环境的内存泄露问题的精准排查。

2.解决方案

出现内存问题时，如果 vmcore 没有捕获到第一现场，无法发现端倪，这时内核同学的传统做法是切换到 debug 内核使用 KASAN 线下调试。然而线上环境复杂，有些十分隐蔽的问题无法在线下稳定复现，或者在线上时本身就属于偶发。这类棘手的问题往往只能搁置，等待下一次出现时期望能提供更多线索。因此，我们看到了 KFENCE 本身的灵活性，对它进行改进，让它成为一个能灵活调整用于线上/线下的内存问题调试工具。

当前最新的 KFENCE 技术优点是可以灵活调节性能开销（以采样率，即捕获 bug 的概率为代价），可不更换内核而通过重启的方式开启；而缺点则是捕获概率太小，以及对于线上场景来说重启也比较麻烦。

我们基于 KFENCE 技术的特点，进行了功能增强，并加上一些全新的设计，使其支持全量监控及动态开关，适用于生产环境，并发布在了龙蜥社区的 Linux 5.10 分支，具体的实现有：

可以在生产环境的 kernel 动态开启和动态关闭。
功能关闭时无任何性能回退。
能够 100% 捕获 slab/order-0 page 的 out-of-bound、memory corruption, use-after-free、 invaild-free 等故障。
能够精准捕获问题发生的第一现场(从这个意义上来看，可以显著加速问题的复现时间)。
支持 per-slab 开关，避免过多的内存和性能开销。
支持 slab/page 内存泄露问题的排查。

对具体技术细节感兴趣的同学可访问龙蜥社区的内核代码仓库阅读相关源码和文档。

2.1 使用方法

2.1.1 功能开启

（可选）配置按 slab 过滤

访问 /sys/kernel/slab/<cache>/kfence_enable 对每个 slab 单独开关。

访问 /sys/module/kfence/parameters/order0_page 控制对于 order-0 page 的监控开关。

采样模式

用户既可以设置启动命令行 kfence.sample_interval=100 并重启来设置系统启动时直接开启 KFENCE（upstream 原版用法），也可以在系统启动后通过 echo100>/sys/module/kfence/parameters/sample_interval 手动打开 KFENCE 的采样功能。

全量模式

首先我们需要对池子大小进行配置。池子大小的估算方法：一个 object 约等于 2 个 page（也就是 8KB）。

考虑将 TLB 页表分裂成 PTE 粒度对周围的影响，最终的池子大小会按 1GB 向上对齐。（object 个数会自动按 131071 向上对齐）如果配置了 slab 过滤功能，可以先不做修改，默认开启 1GB 观察情况。

如果没配置过滤又需要全量监控，个人建议先开个 10GB 观察情况。决定好大小之后，将相应数字写入 /sys/module/kfence/parameters/num_objects 中。

最后通过设置 sample_interval 为-1 来开启。（当然也可以把这俩参数写在启动命令行里，开机即启动）

如何观察情况：kfence 启动后读取 /sys/kernel/debug/kfence/stats 接口，如果两项 currently slab/page allocated 之和接近你设置的 object_size，说明池子大小不够用了，需要扩容（先往 sample_interval 写 0 关闭，再改 num_objects，最后往 sample_interval 写 -1 开启）。

2.1.2 内存被改