生產環境的內存被篡改和內存泄漏如何調試？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

三、總結

• 理論上的覆蓋場景不全

• 內存開銷大

關于回放和課件獲取?