Linux 调测中最最让开发者头疼的 bug 有解了

​一、背景

一直以来，内核内存调测领域一直持续存在着两大行业难题: "内存被改" 和 "内存泄漏"。内存问题行踪诡异、飘忽不定，在 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-bound
char *s = kmalloc(8, GFP_KERNEL);
s[8] = '1';
kfree(s);

//use-after-free
char *s = kmalloc(8, GFP_KERNEL);
kfree(s);
s[0] = '1';

//double-free
char *s = kmalloc(8, GFP_KERNEL);
kf