編者按： 一直持續存在 核心記憶體調測領域兩大行業難題: "記憶體被改" 和 "記憶體洩漏"何解？本文整理自 龍蜥大講堂第 13 期，有效地解決這兩大難題都需要什麼方案？快來看作者的詳細介紹吧！

一、背景

1.1 記憶體被改

Linux 的使用者態的每個程式都單獨擁有自己的虛擬記憶體空間，由 TLB 頁表負責對映管理，從而實現程式間互不干擾的隔離性。然而，在核心態中，所有核心程式共用同一片核心地址空間，這就導致核心程式在分配和使用記憶體時必須小心翼翼。

一個典型的場景例子：現在我們假設使用者  A 向記憶體分配系統申請到了 0x00 到 0x0f 這塊地址，但這只是口頭上的“君子協定”，A不必強制遵守。由於程式缺陷，A 向隔壁的  0x10 寫入了資料，而 0x10 是使用者 B  的地盤。當B試圖讀取自己地盤上的資料的時候，就讀到了錯誤的資料。如果這裡原本存著數值，就會出現計算錯誤從而引起各種不可預估的後果，如果這裡原本是個指標，那整個核心就可能直接當機了。

//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);
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 為什麼調測難

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 列印現場的呼叫棧。從觸發現場到該記憶體的分配/釋放情況一應俱全，從而幫助精準定位問題。

對於記憶體釋放，可配合使用者態指令碼掃描   /sys/kernel/debug/kfence/objects     中活躍的記憶體（只有 alloc 沒有 free 的記錄），找出最多的相同呼叫棧。

2.3 效能影響

2.3.1 hackbench

我們使用 ecs 上的裸金屬機器進行測試，104vcpu 的 Intel Xeon(Cascade Lake) Platinum 8269CY。使用 hackbench 將執行緒設滿（104），根據不同的取樣時間測得效能如下：

2.3.2 sysbench mysql

三、總結

• 理論上的覆蓋場景不全

• 記憶體開銷大

關於回放和課件獲取