搞定 Linux內存難題，Kasan 工具這樣用
做 Linux 開發或運維的朋友，大概率都踩過內存問題的坑：明明代碼邏輯看著沒問題，系統卻時不時崩潰；日志里只飄著 “Segmentation fault”，排查半天找不到具體位置；甚至遇到隱性越界，數據悄悄被篡改卻毫無征兆 —— 這些 “幽靈般” 的內存錯誤，不僅拖慢開發進度，還可能埋下線上故障隱患。
你或許試過用 GDB 斷點調試，卻卡在復雜調用棧里繞不出來；也可能用 Valgrind 檢測，卻受限于性能無法在生產環境使用。其實 Linux 內核早就自帶一款 “內存偵探”——Kasan，能精準揪出越界訪問、使用已釋放內存、內存泄漏等常見問題，甚至能定位到具體代碼行。但不少人對 Kasan 停留在 “聽說過” 的階段：不知道怎么開啟內核配置，不清楚如何解讀檢測日志，更不了解實戰中如何結合場景使用。接下來這篇內容，就從基礎配置講起，帶著你一步步實操 Kasan，教你用它快速定位內存 bug，徹底擺脫 “內存難題排查難” 的困境。
一、Linux 內存管理回顧
在深入探討 Kasan 工具之前，先來了解一下 Linux 內存管理的基本概念。想象一下，你的 Linux 系統就像是一個繁忙的大倉庫，而內存則是這個倉庫中的存儲空間，各個進程就如同在倉庫中存放貨物的客戶。Linux 內存管理的職責，便是高效地分配這些存儲空間，確保每個進程都能獲得所需的內存，同時避免內存浪費和沖突。
1.1Linux內存管理概述
Linux 內存管理采用了虛擬內存技術，為每個進程提供了獨立的地址空間。這就好比每個客戶都有自己獨立的存儲區域，互不干擾。在實際分配內存時，Linux 使用了伙伴系統（Buddy System）和 Slab 分配器等機制。伙伴系統主要負責大塊內存的分配，它將內存劃分為不同大小的塊，并且這些塊總是 2 的冪次大小，當請求分配內存時，伙伴系統會查找與請求大小最匹配的塊，并且如果需要，可以將較大的塊分割成兩個較小的塊；
當內存被釋放時，伙伴系統會檢查相鄰的伙伴塊是否也空閑，如果是的話則合并成一個較大的塊 ，這種方式能夠有效減少內存碎片。而 Slab 分配器則專注于小塊內存的分配，它針對內核中頻繁使用的小對象（如進程描述符、文件描述符等）進行優化，通過緩存這些小對象，提高了內存分配的效率。
內存管理對 Linux 系統的穩定和性能至關重要。如果內存分配不合理，可能導致系統出現內存泄漏，就像倉庫中某些貨物存放混亂，找不到主人也無法清理，隨著時間的推移，可用內存越來越少，最終導致系統運行緩慢甚至崩潰；內存碎片化問題也不容忽視，這就好比倉庫中的空間被零散地分割，雖然總的空間足夠，但卻無法存放大型貨物，使得系統在分配大塊內存時變得困難重重。
1.2常見內存問題
在 Linux 系統中，內存問題可謂是 “隱藏的殺手”，它們常常在不經意間給系統帶來各種麻煩。下面就來看看一些常見的內存問題及其危害。
①越界訪問：內存越界訪問就像是在沒有交通規則的道路上 “越界駕駛”。當程序訪問了不屬于它的內存區域時，就發生了內存越界。這種情況通常發生在數組操作中，比如訪問數組時使用了超出數組大小的索引。例如，定義一個數組int array[10];，正常情況下，數組的索引范圍是從 0 到 9，如果程序中不小心寫成了array[10] = 100;，這就訪問了數組邊界之外的內存，如同汽車駛出了規定的車道，進入了未知區域 。內存越界訪問的危害極大。
它可能導致程序修改了其他重要數據，就像一輛失控的汽車撞到了路邊的重要設施，使得系統出現莫名其妙的錯誤，而且這種錯誤很難調試，因為錯誤發生的位置可能與實際問題代碼相距甚遠，就像事故現場和肇事車輛起始點相隔很遠，增加了排查問題的難度。嚴重時，內存越界訪問會直接導致系統崩潰，使正在運行的服務中斷，造成不可估量的損失。
#include <stdio.h>
#include <string.h>
void demonstrate_memory_corruption() {
int array[10] = {0};
int important_data = 100;
printf("=== 內存越界訪問示例 ===\n");
printf("初始狀態:\n");
printf(" important_data = %d\n", important_data);
// 模擬正常訪問
printf("\n正常訪問 array[5] = 10:\n");
array[5] = 10;
printf(" array[5] = %d\n", array[5]);
printf(" important_data = %d (未受影響)\n", important_data);
// 模擬越界訪問 - 這會覆蓋 important_data
printf("\n 越界訪問 array[10] = 200:\n");
array[10] = 200; // 這里發生了越界！
printf(" array[10] = %d (看似成功)\n", array[10]);
printf(" important_data = %d (被意外修改！)\n", important_data);
// 更嚴重的越界
printf("\n 嚴重越界訪問 array[20] = 999:\n");
array[20] = 999; // 這里訪問了更遠的內存
printf(" 可能導致程序崩潰或不可預測的行為...\n");
}
void demonstrate_array_overflow() {
char buffer[16];
char user_input[] = "This is a very long input that will overflow the buffer";
printf("\n=== 緩沖區溢出示例 ===\n");
printf("緩沖區大小: 16 字節\n");
printf("輸入大小: %zu 字節\n", strlen(user_input));
printf("\n嘗試復制輸入到緩沖區...\n");
strcpy(buffer, user_input); // 危險！沒有檢查邊界
printf("緩沖區內容: %s\n", buffer);
printf("注意: 內存已經被破壞，但程序可能仍然運行\n");
}
int main() {
demonstrate_memory_corruption();
demonstrate_array_overflow();
return 0;
}②使用已釋放內存：使用已釋放的內存，就好比拿著一張過期作廢的車票試圖再次乘車。當程序釋放了一塊內存后，這塊內存就應該被視為 “公共資源”，不再屬于原來的程序。然而，如果程序在釋放內存后，又繼續訪問這塊內存，就會出現使用已釋放內存的問題。
例如，使用malloc分配內存后，用free釋放了它，但后續代碼中又不小心使用了指向這塊已釋放內存的指針 。這種錯誤同樣會引發嚴重后果。由于已釋放的內存可能被操作系統重新分配給其他程序使用，訪問已釋放內存可能導致讀取到錯誤的數據，或者修改了其他程序正在使用的內存，就像用過期車票乘車，可能會誤占他人座位，引發一系列混亂。這會導致程序出現不可預測的行為，從數據錯誤到程序崩潰，嚴重影響系統的穩定性。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void demonstrate_use_after_free() {
printf("=== 使用已釋放內存示例 ===\n");
printf("就像拿著過期車票試圖再次乘車\n\n");
// 分配內存（購買車票）
int *ticket = (int *)malloc(sizeof(int));
*ticket = 2025; // 車票有效期
printf("1. 分配內存 (購買車票):\n");
printf(" 內存地址: %p\n", ticket);
printf(" 車票有效期: %d\n\n", *ticket);
// 釋放內存（車票過期）
free(ticket);
printf("2. 釋放內存 (車票過期作廢):\n");
printf(" 內存已歸還給系統\n\n");
// 錯誤：使用已釋放的內存（使用過期車票）
printf("3. 錯誤：嘗試使用已釋放的內存 (使用過期車票):\n");
printf(" 訪問已釋放內存的地址: %p\n", ticket);
// 這是危險的操作！結果不可預測
printf(" 內存中的垃圾值: %d (可能是隨機數據)\n\n", *ticket);
// 分配新內存，可能會覆蓋之前釋放的內存
int *new_ticket = (int *)malloc(sizeof(int));
*new_ticket = 2026;
printf("4. 系統分配新內存 (新乘客購票):\n");
printf(" 新內存地址: %p\n", new_ticket);
printf(" 新車票有效期: %d\n\n", *new_ticket);
// 現在訪問原來的指針可能會看到新的數據
printf("5. 訪問原指針現在可能指向新數據:\n");
printf(" 原指針地址: %p\n", ticket);
printf(" 原指針現在的值: %d (可能是新數據)\n", *ticket);
free(new_ticket);
}
void demonstrate_dangling_pointer() {
printf("\n=== 懸空指針示例 ===\n");
char *username = (char *)malloc(20);
strcpy(username, "Alice");
printf("1. 分配字符串內存:\n");
printf(" 用戶名: %s\n", username);
free(username);
printf("2. 釋放內存后:\n");
// 懸空指針：指向已釋放內存的指針
printf(" 懸空指針仍然指向: %p\n", username);
// 危險：指針仍然存在，但指向的內存已無效
printf(" 嘗試訪問: %s (可能顯示垃圾數據)\n", username);
// 正確做法：釋放后將指針置為NULL
username = NULL;
printf("3. 正確做法：釋放后將指針置為NULL:\n");
printf(" 指針現在: %p\n", username);
// 現在訪問會導致明顯的錯誤，而不是隱藏的問題
// if (username != NULL) {
// printf(" 安全訪問: %s\n", username);
// }
}
int main() {
demonstrate_use_after_free();
demonstrate_dangling_pointer();
return 0;
}③內存泄漏：內存泄漏則像是一個看不見的漏洞，讓內存資源無聲無息地流失。當程序動態分配了內存，卻在不再需要時沒有釋放這些內存，就會發生內存泄漏。比如在 C 語言中，使用malloc分配了內存，但沒有相應的free操作；在 C++ 中，使用new分配內存后，沒有使用delete釋放 。隨著內存泄漏的不斷積累，系統的可用內存會越來越少，就像一個水池，不斷有水流入，但排水口卻被堵住，水池里的水越來越少，無法滿足后續的需求。
這會導致系統性能逐漸下降，程序運行變得緩慢，因為系統需要不斷地進行內存交換操作，從磁盤中讀取數據來補充內存的不足。最終，當內存被耗盡時，程序可能會崩潰，服務中斷，給用戶帶來極差的體驗，對于一些關鍵業務系統，甚至可能造成巨大的經濟損失。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
// 模擬內存泄漏的函數
void leak_memory(int count) {
printf("=== 內存泄漏示例 ===\n");
printf("就像一個看不見不見的漏洞，讓內存資源無聲無息地流失\n\n");
for (int i = 0; i < count; i++) {
// 分配內存但不釋放 - 內存泄漏發生
char *data = (char *)malloc(1024 * 1024); // 每次分配1MB
if (data != NULL) {
// 寫入一些數據
memset(data, 0xAA, 1024 * 1024);
// 模擬一些處理...
// 但忘記釋放內存！
printf("泄漏第 %d 次: 分配了 1MB 內存\n", i + 1);
} else {
printf("內存分配失??！系統可能已經耗盡內存\n");
break;
}
}
printf("\n 警告：已經泄漏了 %d MB 內存，并且沒有釋放！\n", count);
printf("這些內存將一直被占用，直到程序結束\n");
}
// 正確的內存管理示例
void proper_memory_management(int count) {
printf("\n=== 正確的內存管理 ===\n");
for (int i = 0; i < count; i++) {
char *data = (char *)malloc(1024 * 1024);
if (data != NULL) {
// 使用內存
memset(data, 0xBB, 1024 * 1024);
// 重要：使用完后釋放內存
free(data);
printf("正確處理第 %d 次: 分配并釋放了 1MB 內存\n", i + 1);
} else {
printf("內存分配失敗！\n");
break;
}
}
printf("\n 正確：所有分配的內存都已釋放\n");
}
// 更復雜的內存泄漏場景
void complex_memory_leak() {
printf("\n=== 復雜的內存泄漏場景 ===\n");
// 模擬一個函數，在某些條件下忘記釋放內存
for (int i = 0; i < 5; i++) {
int *numbers = (int *)malloc(100 * sizeof(int));
if (numbers != NULL) {
// 初始化數據
for (int j = 0; j < 100; j++) {
numbers[j] = j;
}
// 模擬條件判斷，某些情況下忘記釋放
if (i % 2 == 0) {
// 偶數次不釋放 - 內存泄漏
printf("條件成立，忘記釋放內存 (泄漏)\n");
} else {
// 奇數次釋放
free(numbers);
printf("條件不成立，正確釋放內存\n");
}
}
}
printf("\n 這個函數泄漏了部分內存\n");
}
int main() {
// 演示內存泄漏
leak_memory(5); // 泄漏5MB內存
// 演示正確的內存管理
proper_memory_management(5);
// 演示復雜的內存泄漏場景
complex_memory_leak();
printf("\n=== 內存泄漏的危害 ===\n");
printf("1. 系統可用內存逐漸減少\n");
printf("2. 程序運行越來越慢\n");
printf("3. 可能導致系統崩潰\n");
printf("4. 影響其他程序的正常運行\n");
return 0;
}二、認識 Kasan 這位 “內存偵探”
面對這些棘手的內存問題，有沒有一種有效的工具能夠幫助我們快速定位和解決問題呢？答案就是 Kasan。
2.1 Kasan 是什么？
在探尋如何有效檢測內存錯誤的道路上，Kasan （全稱為 Kernel Address Sanitizer）工具應運而生，它的出現為內存錯誤檢測領域帶來了新的曙光 。Kasan，全稱為 Kernel Address Sanitizer，即內核地址清理器，它是 AddressSanitizer 針對 Linux 內核的一個分支，最初由 Google 的工程師開發，目的就是專門用于檢測 Linux 內核中的內存錯誤。
AddressSanitizer 是一個廣泛應用于用戶空間程序內存錯誤檢測的工具，憑借在檢測堆緩沖區溢出、棧緩沖區溢出、使用已釋放內存等方面的出色表現，深受開發者喜愛。而 Kasan 則是借鑒了 AddressSanitizer 的設計思想和關鍵技術，將其應用場景拓展到了 Linux 內核領域。
Kasan 的發展歷程與 Linux 內核的發展緊密相連。在早期的 Linux 內核開發中，內存錯誤的檢測和調試主要依賴于一些簡單的工具和開發者的經驗。隨著 Linux 內核的不斷發展壯大，功能日益豐富，代碼量也急劇增加，傳統的內存錯誤檢測方法越來越難以滿足需求。那些隱藏在復雜內核代碼深處的內存錯誤，就像潛藏在黑暗中的 “暗流”，難以被發現和處理，給系統的穩定性和安全性帶來了極大的威脅。
Kasan 的出現，成功地填補了這一空白。自它被引入 Linux 內核以來，就迅速成為內核開發者不可或缺的得力助手。它在 Linux 內核版本演進中不斷優化和完善，功能也越來越強大。如今，Kasan 已經成為 Linux 內核開發和維護過程中檢測內存錯誤的標準工具之一，為保障 Linux 系統的穩定運行發揮著重要作用。就像在 Linux 內核這片廣闊的 “戰場” 上，Kasan 就是那把鋒利的 “寶劍”，幫助開發者披荊斬棘，戰勝內存錯誤帶來的種種挑戰。
2.2 Kasan 工作原理與機制
Kasan 利用了一種巧妙的 “影子內存”（shadow memory）技術來實現內存錯誤檢測。簡單來說，影子內存是一塊與實際內存相對應的額外內存區域，它就像是實際內存的 “影子”，如影隨形。Kasan 為每 8 字節的實際內存分配 1 字節的影子內存 ，通過影子內存中的標記來記錄對應實際內存區域的訪問權限和狀態。例如，當一段內存被分配且未被釋放時，其對應的影子內存標記為可訪問狀態；當內存被釋放后，影子內存會被標記為不可訪問狀態。
當程序嘗試訪問內存時，Kasan 會檢查對應的影子內存標記。如果影子內存標記表明該訪問是合法的，程序可以正常訪問內存；如果影子內存標記顯示該訪問不合法，比如訪問了已釋放內存或越界訪問，Kasan 就會立即捕獲到這個錯誤，并輸出詳細的錯誤信息，包括出錯的地址、訪問的大小以及相關的調用棧信息，就像偵探在犯罪現場收集線索一樣，幫助開發者快速定位到問題代碼所在。
（1）影子內存：核心奧秘
Kasan 能夠高效檢測內存錯誤，其核心奧秘在于 “影子內存”。簡單來說，影子內存就像是實際內存的 “孿生兄弟”，Kasan 會為每一塊實際使用的內存分配一塊與之對應的影子內存區域，二者大小相同 。影子內存的主要任務是存儲對應實際內存區域的狀態信息，這些信息就像是內存的 “健康檔案”，詳細記錄著內存的各種情況。
在實際運行中，影子內存通過特殊的編碼方式來標記內存的狀態。例如，當影子內存中的某個位置的值為 0 時，就表示對應的實際內存區域是完全可以正常訪問的，就像一個暢通無阻的道路，程序可以自由地讀取和寫入數據；而當影子內存的值為負數時，則代表對應的內存區域存在問題，比如可能是已經被釋放的內存，或者是越界訪問的區域，這就好比道路上設置了 “禁止通行” 的標志，程序如果試圖訪問，Kasan 就能立刻察覺并發出警報。
以一個簡單的數組訪問為例，假設我們定義了一個包含 10 個元素的整數數組int arr[10];，系統會為這個數組分配一塊連續的內存空間來存儲這 10 個整數。與此同時，Kasan 會為這塊內存分配對應的影子內存。當程序執行arr[5] = 10;這樣的操作時，Kasan 會先檢查影子內存中對應arr[5]的位置，確認該位置標記為可訪問狀態（通常為 0），才會允許這次賦值操作順利進行。但如果程序中出現了arr[15] = 20;這樣的越界訪問，Kasan 檢查影子內存時，會發現對應arr[15]的位置標記并非可訪問狀態，于是馬上判定這是一次非法訪問，并及時報告錯誤，就像一個嚴格的交通警察，絕不允許任何違規的 “內存通行” 行為。
C 語言代碼示例如下：
#include <stdio.h>
#include <stdlib.h>
// 簡單模擬 Kasan 的影子內存檢查
#define ARRAY_SIZE 10
// 模擬影子內存 (每個字節對應 8 個字節的應用內存)
unsigned char shadow_memory[ARRAY_SIZE / 8 + 1] = {0};
// 初始化影子內存
void init_shadow() {
// 標記前 10 個整數（40 字節）為可訪問
for (int i = 0; i < 5; i++) {
shadow_memory[i] = 0x00; // 0 表示可訪問
}
// 標記其余部分為不可訪問
for (int i = 5; i < sizeof(shadow_memory); i++) {
shadow_memory[i] = 0xff; // 非 0 表示不可訪問
}
}
// 檢查內存訪問是否合法
int check_memory_access(void *ptr, size_t size) {
size_t addr = (size_t)ptr;
size_t base = (size_t)malloc(ARRAY_SIZE * sizeof(int));
size_t offset = addr - base;
// 計算影子內存索引和位
size_t shadow_index = offset / 8;
size_t shadow_bit = offset % 8;
// 檢查影子內存
if (shadow_index >= sizeof(shadow_memory)) {
return 0; // 越界
}
// 檢查對應位是否為 0
if ((shadow_memory[shadow_index] & (1 << shadow_bit)) != 0) {
return 0; // 不可訪問
}
return 1; // 合法訪問
}
int main() {
int *arr = (int *)malloc(ARRAY_SIZE * sizeof(int));
init_shadow();
printf("=== Kasan 內存檢查示例 ===\n");
// 合法訪問
printf("嘗試訪問 arr[5] = 10: ");
if (check_memory_access(&arr[5], sizeof(int))) {
arr[5] = 10;
printf("訪問成功\n");
} else {
printf("非法訪問！\n");
}
// 越界訪問
printf("嘗試訪問 arr[15] = 20: ");
if (check_memory_access(&arr[15], sizeof(int))) {
arr[15] = 20;
printf(" 訪問成功\n");
} else {
printf(" 非法訪問！\n");
}
free(arr);
return 0;
}- 影子內存初始化：為數組分配對應的影子內存，并標記可訪問區域
- 內存訪問檢查：在每次內存訪問前檢查影子內存
- 越界檢測：對于越界訪問能夠及時發現并報告
編譯運行后，你會看到：
=== Kasan 內存檢查示例 ===
嘗試訪問 arr[5] = 10: 訪問成功
嘗試訪問 arr[15] = 20: 非法訪問！這就是 Kasan 如何像交通警察一樣監控內存訪問，防止越界等內存錯誤。
（2）編譯時插樁：關鍵環節
除了影子內存這一核心技術，Kasan 還有一個關鍵的工作環節，那就是編譯時插樁。在 Linux 內核編譯的過程中，Kasan 會巧妙地插入一些額外的檢查代碼，這些代碼就像是隱藏在程序中的 “小哨兵”，時刻監視著內存的訪問情況。
這些檢查代碼會在內存訪問指令之前被插入，比如在進行內存讀?。╨oad）或者寫入（store）操作前，檢查代碼會先執行。它的主要職責是查詢影子內存中對應位置的狀態信息，以此來判斷即將進行的內存訪問是否合法。例如，當程序執行一條從內存中讀取數據的指令時，編譯時插入的檢查代碼會迅速查詢影子內存，確認該內存區域是否允許被讀取。如果影子內存標記該區域可訪問，那么讀取指令才能正常執行；反之，如果影子內存標記該區域不可訪問，檢查代碼就會立即觸發錯誤報告機制。
Kasan 還會接管內存管理函數，比如常見的內存分配函數malloc和內存釋放函數free。當程序調用malloc分配內存時，Kasan 會在背后記錄下分配的內存地址、大小等關鍵信息，并相應地在影子內存中做好標記；當調用free釋放內存時，Kasan 同樣會更新影子內存，將對應內存區域標記為已釋放狀態，禁止再次訪問。這就好比一個圖書館管理員，對每一本書的借出（內存分配）和歸還（內存釋放）都了如指掌，并做好記錄，防止出現混亂。
一旦 Kasan 檢測到內存訪問錯誤，它會迅速生成詳細的錯誤報告。報告中會包含錯誤的類型，比如是越界訪問還是使用已釋放內存；還會明確指出錯誤發生的具體內存地址，以及相關的調用棧信息，這些信息就像是一張詳細的 “錯誤地圖”，能夠幫助開發者快速定位到問題代碼所在，準確找出內存錯誤的根源，從而高效地進行修復。
2.3 Kasan 集成配置
將 Kasan 集成到 Linux 內核中，是充分發揮其內存錯誤檢測能力的關鍵一步 ，這一過程雖然需要開發者投入一定的精力，但卻能為后續的開發和調試工作帶來極大的便利。以 Linux 內核 5.10 版本為例，我們來詳細了解一下具體的集成步驟。
首先，確保開發環境中安裝了 Linux 內核 5.10 的源代碼。你可以從官方的 Linux 內核鏡像站點下載對應的源代碼壓縮包，下載完成后，使用解壓命令將其解壓到指定的目錄，例如/usr/src/linux-5.10。
接著，進入解壓后的內核源代碼目錄，使用make menuconfig命令打開內核配置界面。這就像是打開了一個龐大的 “功能超市”，在這里你可以對內核的各種功能進行選擇和配置。在配置界面中，通過方向鍵和回車鍵，依次找到 “Kernel hacking” -> “Memory Debugging” 選項，然后在其中找到 “KASAN: runtime memory debugger” 選項，按下空格鍵將其選中，使其前面的括號內顯示為 “*”，這表示啟用 Kasan 功能。
對于一些追求極致性能和個性化配置的開發者來說，還可以進一步深入配置。比如，在 “KASAN: runtime memory debugger” 的子選項中，有 “KASAN: inline instrumentation (EXPERIMENTAL)” 選項。這個選項涉及到 Kasan 的檢測模式，內聯模式（inline instrumentation）會在編譯時將檢查代碼直接插入到內存訪問代碼中，檢測更加精細，但可能會對性能產生一定影響；而輪詢模式（outline instrumentation）則是在運行時進行檢查，對性能影響相對較小。你可以根據自己的需求和對性能的考量來選擇合適的模式。
完成所有配置后，按下 “Esc” 鍵退出配置界面，并保存配置。接下來，就可以開始編譯內核了。在終端中執行make -j$(nproc)命令，其中-j$(nproc)參數表示使用系統的所有 CPU 核心進行并行編譯，這樣可以大大加快編譯速度。編譯過程可能會持續一段時間，具體時長取決于你的硬件性能和內核代碼的復雜程度，在這個過程中，你可以耐心等待，或者去做一些其他的事情。
編譯完成后，還需要安裝編譯好的內核模塊和內核。依次執行make modules_install和make install命令，這兩個命令會將編譯好的內核模塊安裝到系統的對應目錄中，并更新系統的啟動配置，使新的內核能夠在下次啟動時生效。最后，重啟系統，在啟動過程中，選擇新安裝的帶有 Kasan 功能的內核，至此，Kasan 就成功集成到 Linux 內核中了。
Kasan 提供了一系列豐富的配置參數，這些參數就像是調節工具性能的 “旋鈕”，通過合理調整它們，能夠讓 Kasan 在不同的應用場景中發揮出最佳的檢測效果 。先來說說CONFIG_KASAN_RECORD這個參數，當它被啟用時，Kasan 會記錄更多關于內存訪問的詳細信息，包括內存的分配和釋放歷史等。這對于調試一些復雜的內存問題非常有幫助，比如在追蹤一個難以捉摸的內存泄漏問題時，開啟CONFIG_KASAN_RECORD，Kasan 記錄的信息就像是一份詳細的 “內存使用日志”，開發者可以從中清晰地看到內存是在哪些函數中被分配和釋放的，從而更容易找到問題的根源。但需要注意的是，啟用這個參數會增加一定的系統開銷，因為記錄這些信息需要占用額外的系統資源。
再看CONFIG_KASAN_HW_TAGS參數，它主要用于支持硬件標簽的 Kasan 模式，這種模式僅在支持內存標記擴展（MTE）的 arm64 CPU 上運行 。在這種模式下，硬件會協助 Kasan 進行內存訪問的檢測，大大提高檢測效率，并且內存和性能開銷都相對較低，因此非常適合在對性能要求較高的生產環境中使用。例如，在一些基于 arm64 架構的服務器上，啟用CONFIG_KASAN_HW_TAGS，既能保障系統的穩定運行，又能及時檢測出潛在的內存錯誤。
對于一些對性能極為敏感的應用場景，CONFIG_KASAN_LOW_OVERHEAD模式就派上用場了。啟用這個模式后，Kasan 會采用一些優化策略來降低對系統性能的影響，雖然可能會犧牲掉一部分檢測的全面性，但在那些對性能要求苛刻，且內存錯誤風險相對較低的場景中，這是一個很好的平衡選擇。比如在一些實時性要求很高的多媒體處理應用中，使用CONFIG_KASAN_LOW_OVERHEAD模式，既能保證應用的流暢運行，又能在一定程度上檢測內存錯誤。
還有CONFIG_KASAN_CONCURRENT參數，它主要用于支持并發環境下的內存錯誤檢測。在一些多線程、多進程并發執行的復雜應用中，內存訪問的情況更加復雜，容易出現一些只有在并發環境下才會出現的內存錯誤。啟用CONFIG_KASAN_CONCURRENT，Kasan 就能更好地捕捉這些并發相關的內存問題，保障系統在并發場景下的穩定性。
三、Kasan 實戰：揪出內存問題 “元兇”
理論知識儲備完成，接下來就進入實戰環節，看看 Kasan 是如何在實際操作中發揮作用，揪出內存問題的 “元兇” 的。
3.1準備工作
在使用 Kasan 之前，需要確保內核已經開啟了相關的配置選項。首先，要保證 CONFIG_HAVE_ARCH_KASAN 和 CONFIG_KASAN 這兩個配置項被啟用。CONFIG_HAVE_ARCH_KASAN 表示當前架構是否支持 Kasan ，而 CONFIG_KASAN 則是開啟 Kasan 功能的關鍵配置。
開啟這些配置選項的方式通常是通過內核配置工具，如 make menuconfig。在配置界面中，找到 “Kernel hacking” 選項，進入后找到 “Memory Debugging” 相關子菜單，在其中可以找到 Kasan 的配置項，將 CONFIG_KASAN 設置為 “y”，表示啟用 Kasan 。如果希望獲得更詳細的調試信息，還可以開啟 CONFIG_KASAN_EXTRA_INFO 等相關選項。
需要注意的是，開啟 Kasan 可能會對系統性能產生一定的影響，因為它需要額外的內存和計算資源來維護影子內存和進行內存訪問檢查 。所以在生產環境中使用時，需要謹慎評估。同時，不同的內核版本和架構可能對 Kasan 的支持和配置方式略有差異，在實際操作時要參考對應的內核文檔和資料。
3.2案例一：越界訪問排查
我們來看一段簡單的 C 語言代碼示例，這段代碼模擬了一個在 Linux 內核模塊中可能出現的越界訪問情況 。
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
static int __init kasan_demo_init(void) {
char *buffer;
size_t buffer_size = 10;
buffer = kmalloc(buffer_size, GFP_KERNEL);
if (!buffer) {
printk(KERN_ERR "Memory allocation failed\n");
return -ENOMEM;
}
// 故意越界訪問，將數據寫入超出分配內存的位置
buffer[buffer_size + 1] = 'A';
kfree(buffer);
printk(KERN_INFO "Module initialized successfully\n");
return 0;
}
static void __exit kasan_demo_exit(void) {
printk(KERN_INFO "Module exited successfully\n");
}
module_init(kasan_demo_init);
module_exit(kasan_demo_exit);
MODULE_LICENSE("GPL");當這段代碼在內核中運行并啟用 Kasan 后，Kasan 會迅速檢測到越界訪問錯誤，并生成詳細的錯誤報告 。錯誤報告大致如下：
==================================================================
BUG: KASAN: slab-out-of-bounds in kasan_demo_init+0x74/0x98 at addr ffffffff88888888
Write of size 1 by task <your_task_name>/<pid>
CPU: <cpu_number> PID: <pid> Comm: <your_task_name> Tainted: <taint_info> <kernel_version> #<build_number>
Hardware name: <your_hardware_name>
Call trace:
[<ffffffff81000000>] dump_backtrace+0x0/0x358
[<ffffffff81000014>] show_stack+0x14/0x20
[<ffffffff810000a8>] dump_stack+0xa8/0xd0
[<ffffffff810003c4>] kasan_object_err+0x24/0x80
[<ffffffff81000654>] kasan_report.part.1+0x1dc/0x498
[<ffffffff81000b98>] qlist_move_cache+0x0/0xc0
[<ffffffff81000fe4>] __asan_store1+0x4c/0x58
[<ffffffffc0000074>] kasan_demo_init+0x74/0x98 [your_module_name]
Object at ffffffff88888880, in cache kmalloc-<size> size: <allocated_size>
Allocated:
[<ffffffffc0000000>] kasan_demo_init+0x30/0x98 [your_module_name]在這份錯誤報告中，“BUG: KASAN: slab-out-of-bounds” 明確指出錯誤類型是越界訪問 。“kasan_demo_init+0x74/0x98” 表示錯誤發生在kasan_demo_init函數中，偏移地址為 0x74，函數總大小為 0x98，這就像是在一個房子里（函數），告訴你錯誤發生在房子里的具體位置（偏移地址）。“at addr ffffffff88888888” 指出了越界訪問的具體內存地址，這是定位問題的關鍵線索之一，就像給了你錯誤發生的 “門牌號”?！癢rite of size 1” 說明是一次寫入操作，寫入大小為 1 字節，讓你清楚了解錯誤的操作類型和數據量。
根據這份報告，我們可以迅速定位到代碼中buffer[buffer_size + 1] = 'A';這一行，這就是導致越界訪問的罪魁禍首。要修復這個問題，只需確保內存訪問不超出分配的范圍，比如修改為buffer[buffer_size - 1] = 'A';，這樣就保證了訪問在合法的內存區間內。
3.3案例二：釋放后使用問題解決
接下來看一個釋放后使用內存的代碼示例 。
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
static int __init kasan_use_after_free_init(void) {
char *buffer;
size_t buffer_size = 10;
buffer = kmalloc(buffer_size, GFP_KERNEL);
if (!buffer) {
printk(KERN_ERR "Memory allocation failed\n");
return -ENOMEM;
}
kfree(buffer);
// 嘗試訪問已釋放的內存
buffer[5] = 'B';
printk(KERN_INFO "Module initialized successfully\n");
return 0;
}
static void __exit kasan_use_after_free_exit(void) {
printk(KERN_INFO "Module exited successfully\n");
}
module_init(kasan_use_after_free_init);
module_exit(kasan_use_after_free_exit);
MODULE_LICENSE("GPL");當啟用 Kasan 運行這段代碼時，Kasan 會檢測到釋放后使用內存的錯誤，并給出如下報告 ：
==================================================================
BUG: KASAN: use-after-free in kasan_use_after_free_init+0x6c/0x98 at addr ffffffff88888888
Write of size 1 by task <your_task_name>/<pid>
CPU: <cpu_number> PID: <pid> Comm: <your_task_name> Tainted: <taint_info> <kernel_version> #<build_number>
Hardware name: <your_hardware_name>
Call trace:
[<ffffffff81000000>] dump_backtrace+0x0/0x358
[<ffffffff81000014>] show_stack+0x14/0x20
[<ffffffff810000a8>] dump_stack+0xa8/0xd0
[<ffffffff810003c4>] kasan_object_err+0x24/0x80
[<ffffffff81000654>] kasan_report.part.1+0x1dc/0x498
[<ffffffff81000b98>] qlist_move_cache+0x0/0xc0
[<ffffffff81000fe4>] __asan_store1+0x4c/0x58
[<ffffffffc000006c>] kasan_use_after_free_init+0x6c/0x98 [your_module_name]
Freed by task <your_task_name>/<pid>; stack:
[<ffffffff81000000>] dump_backtrace+0x0/0x358
[<ffffffff81000014>] show_stack+0x14/0x20
[<ffffffff810000a8>] dump_stack+0xa8/0xd0
[<ffffffff810003c4>] kasan_object_err+0x24/0x80
[<ffffffff81000654>] kasan_report.part.1+0x1dc/0x498
[<ffffffff81000b98>] qlist_move_cache+0x0/0xc0
[<ffffffff81000fe4>] __asan_store1+0x4c/0x58
[<ffffffffc0000048>] kasan_use_after_free_init+0x48/0x98 [your_module_name]
Object at ffffffff88888880, in cache kmalloc-<size> size: <allocated_size>
Freed:
[<ffffffffc0000048>] kasan_use_after_free_init+0x48/0x98 [your_module_name]從報告中 “BUG: KASAN: use-after-free” 可以得知這是一個釋放后使用內存的錯誤 。“kasan_use_after_free_init+0x6c/0x98” 指出錯誤發生在kasan_use_after_free_init函數的特定位置?！癮t addr ffffffff88888888” 給出了錯誤發生的內存地址。報告中還特別指出 “Freed by task <your_task_name>/”，并列出了內存被釋放時的堆棧信息，這對于追蹤內存釋放的源頭非常有幫助，就像為你提供了一條從錯誤發生點回溯到內存釋放點的 “線索鏈”。
根據這份報告，我們可以輕松定位到代碼中kfree(buffer);之后的buffer[5] = 'B';這一行，這就是問題所在。要修復這個問題，需要確保在內存釋放后不再訪問該內存，比如可以將buffer指針設置為NULL，即kfree(buffer); buffer = NULL;，這樣后續如果不小心再次訪問buffer，就會因為buffer為NULL而觸發空指針異常，從而更容易發現和解決問題 。
