生产环境的内存被篡改和内存泄漏如何调试？kfence来帮忙

编者按：之前我们介绍了内核并发消杀器KCSAN，有小伙伴希望介绍下内核内存方面的工具，这次为大家带来适合生产环境的工具：kfence。

以下文章来自OpenAnolis龙蜥，作者Kernel SIG成员

一、背景

1.1 内存被改

//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 为什么调测难

1.1.2 现有方案的局限性

• 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 为什么调测难

1.2.2 现有方案的局限性

二、解决方案

• 可以在生产环境的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 过滤

• 采样模式

• 全量模式

2.1.2 内存被改

2.1.3 内存泄漏

2.2 使用效果

对于内存被改，抓到该行为后会在 dmesg 打印现场的调用栈。从触发现场到该内存的分配/释放情况一应俱全，从而帮助精准定位问题。

2.3 性能影响

2.3.1 hackbench

2.3.2 sysbench mysql

三、总结

• 理论上的覆盖场景不全

• 内存开销大

关于回放和课件获取