Linux 內核熱補丁可以修復正在運行的 linux 內核，是一種維持線上穩定性不可缺少的措施，現在比較常見的比如 kpatch 和 livepatch。內核熱補丁可以修復內核中正在運行的函數，用已修復的函數替換掉內核中存在問題的函數從而達到修復目的。

函數替換的思想比較簡單，就是在執行舊函數時繞開它的執行邏輯而跳轉到新的函數中，有一種比較簡單粗暴的方式，就是將原函數的第一條指令修改為“ jump 目標函數”指令，即直接跳轉到新的函數以達到替換目的。

那么，問題來了，這么做靠譜嗎？直接將原函數的第一條指令修改為 jump 指令，會破壞掉原函數和它的調用者之間的寄存器上下文關系，存在安全隱患！本文會針對該問題進行探索和驗證。

安全性沖擊：問題呈現

對于函數調用，假設存在這樣兩個函數 funA 和 funB，其中 funA 調用 funB 函數，這里稱 funA 為 caller（調用者），funB 為 callee（被調用者），funA 和 funB 都使用了相同的寄存器 R，如下所示：

圖1 funA 和 funB 都使用了寄存器 R，funA 再次使用 R 時已經被 funB 修改

因此，當 funA 再次使用到 R 的數據已經是錯誤的數據了。如果 funA 在調用 funB 前保存寄存器 R 中的數據，funB 返回后再將數據恢復到 R 中，或者 funB 先保存 R 中原有的數據，然后在返回前恢復，就可以解決這類問題。

唯一的調用約定

那寄存器該由 caller 還是 callee 來保存？這就需要遵循函數的調用約定（call convention），不同的 ABI 和不同的平臺，函數的調用約定是不一樣的，對于 Linux 來說，它遵循的是 System V ABI 的 call convention，x86_64 平臺下函數調用約定有且只有一種，調用者 caller 和被調用者 callee 需要對相應的寄存器進行保存和恢復操作：

Caller-save registers ： RDI， RSI， RDX， RCX， R8， R9， RAX， R10， R11

Callee-save registers ： RBX， RBP， R12， R13， R14， R15

調用約定，gcc 它遵守了嗎？

設問：當函數實現很簡單，只用到了少量寄存器，那沒使用到的還需要保存嗎？

答案：it depends。根據編譯選項決定。

眾所周知，GCC 編譯器有 -O0、-O1、-O2 和 -Ox 等編譯優化選項，優化范圍和深度隨 x 增大而增大（-O0是不優化，其中隱含的意思是，它會嚴格遵循 ABI 中的調用約定，對所有使用的寄存器進行保存和恢復）。

Linux 內核選用的都是 -O2 優化。GCC 會選擇性的不遵守調用約定，也就是設問里提到的，不需要保存沒使用到的寄存器。當【運行時替換】撞見【調用約定】

GCC 之所以可以做這個優化，是因為 GCC 高屋建瓴，了解程序的執行流。當它知道 callee，caller 的寄存器分配情況，就會大膽且安全地做各種優化。

但是，運行時替換破壞了這個假設，GCC 所掌握的 callee 信息，極有可能是錯誤的。那么這些優化可能會引發嚴重問題。這里以一個具體的實例進行詳細說明，這是一個用戶態的例子（ x86_64 平臺）：

//test.c 文件//編譯命令：gcc test.c -o test -O2 （kernel 采用的是 O2 優化選項）//執行過程：。/test//輸入參數：4

#include 《sys/mman.h》#include 《string.h》#include 《stdio.h》#include 《math.h》

#define noinline __attribute__ （（noinline）） //禁止內聯

static noinline int c（int x）{ return x * x * x;}

static noinline int b（int x）{ return x;}

static noinline int newb（int x）{ return c（x * 2） * x;}

static noinline int a（int x）{ int volatile tmp = b（x）; // tmp = 8 ** 3 * 4 return x + tmp; // return 4（not 8） + tmp}

int main（void）{ int x; scanf（“%d”， &x）;

if （mprotect（（void*）（（（unsigned long）&b） & （~0xFFFF））， 15， PROT_WRITE | PROT_EXEC | PROT_READ）） { perror（“mprotect”）; return 1; }

/* 利用 jump 指令將函數 b 替換為 newb 函數 */ （（char*）b）［0］ = 0xe9; *（long*）（（unsigned long）b + 1） = （unsigned long）&newb - （unsigned long）&b - 5; printf（“%d”， a（x））; return 0;}

程序解釋：該程序是對輸入的數字進行計算，運行時利用 jump 指令將程序中的函數 b 替換為 newb 函數，即，將 y = x + x 計算過程替換為 y = x + （2x） ^ 3 * x；

程序編譯：gcc test.c -o test -O2，這里我們采用的是與編譯內核相同的優化選項 -O2；

程序執行：。/test，輸入參數：4，輸出結果：2056；

程序錯誤：2056 是錯誤的結果，應該是 2052，而且直接調用 newb 函數編譯執行的結果是 2052。

該例子說明，直接使用 jump 指令替換函數在 -O2 的編譯優化下，會出現問題，安全性受到了質疑和沖擊！！！

安全性沖擊：分析問題

上述例子中，我們將函數 b 用 jump 指令替換為 newb 函數，在 -O2 的編譯優化下出現了計算錯誤的結果，因此，我們需要對函數的調用執行過程進行仔細分析，挖掘問題所在。首先，我們先來查看一下該程序的反匯編（指令：objdump -d test），并重點關注 a、b 和 newb 函數：

圖2 -O2 編譯優化的反匯編結果

匯編解釋：main：-》 將參數 4 存放到 edi 寄存器中-》 調用 a 函數：-》 調用 b 函數，直接跳轉到 newb 函數： -》 將 edi 寄存器中的值存放到 edx 寄存器 -》 edi 寄存器與自身相加后結果放入 edi -》 調用 c 函數： -》 將 edi 寄存器中的值存到 eax 寄存器 -》 edi 乘以 eax 后結果放入 eax -》 edi 乘以 eax 后結果放入 eax -》 返回到 newb 函數 -》 將 edx 與 eax 相乘后結果放入 eax-》 返回到 a 函數-》 將 edi 與 eax 相加后結果放入 eax-》 返回 main 函數

（注意：b 函數中沒有對 edi 寄存器進行寫操作，而且它的代碼段被修改為 jump 指令跳轉到 newb 函數）

數據出錯的原因在于，在函數 newb 中，使用到了 a 函數中使用的 edi 寄存器，edi 寄存器中的值在 newb 函數中被修改為 8，當 newb 函數返回后，edi 的值仍然是 8，a 函數繼續使用了該值，因此，計算過程變為：8^3 * 4 + 8 = 2056，而正確的計算結果應該是 8^3 * 4 + 4 = 2052。

接下來不進行編譯優化（-O0），其輸出結果是正確的 2052，反匯編如下所示：

圖3 不進行編譯優化的反匯編

從反匯編中可以看到，函數 a 在調用 b 函數前，將 edi 寄存器的值存在了棧上，調用之后，將棧上的數據再取出，最后進行相加。這就說明，-O2 優化選項將 edi 寄存器的保存和恢復操作優化掉了，而在調用約定中，edi 寄存器本就該屬于 caller 進行保存/恢復的。至于為什么編譯器會進行優化，我們此刻的猜想是：

a 函數本來調用的是 b 函數，而且編譯器知道 b 函數中沒有使用到 edi 寄存器，因此調用者 a 函數沒有對該寄存器進行保存和恢復操作。但是編譯器不知道的是，在程序運行時，b 函數的代碼段被動態修改，利用 jump 指令替換為 newb 函數，而在 newb 函數中對 edi 寄存器進行了數據讀寫操作，于是出現了錯誤。

這是一個典型的沒有保存 caller-save 寄存器導致數據出錯的場景。而編譯內核采用的也是 -O2 選項。如果將該場景應用到內核函數熱替換是否會出現這類問題呢？于是，我們帶著問題繼續探索。

安全性沖擊：探索問題

不再觀察到 bug

我們構造了一個內核函數熱替換的實例，將上面的用戶態的例子移植到我們構造的場景中，通過內核模塊修改原函數的代碼段，用 jump 指令直接替換原來的 b 函數。然而加載模塊后，結果是正確的 2052，經過反匯編我們發現，內核中 a 函數對 edi 寄存器進行了保存操作：

圖4 內核中 a 函數的反匯編

內核和模塊編譯時采用的是 -O2 優化選項，而此處 a 函數并沒有被優化，仍然保存了 edi 寄存器。

此時我們預測：對于內核函數的熱替換來說，使用 jump 做函數替換是安全的。

神奇的 -pg 選項

我們猜想是否是內核編譯時使用其它的編譯選項導致問題不能復現。果不其然，經過探索我們發現內核編譯使用的 -pg 選項導致問題不再復現。

通過翻閱 GCC 手冊得知，-pg 選項是為了支持 GNU 的 gprop 性能分析工具所引入的，它能在函數中增加一條 call mount 指令，去做一些分析工作。

在內核中，如果開啟了 CONFIG_FUNCTION_TRACER，則會使能 -pg 選項。

圖5 開啟 CONFIG_FUNCTION_TRACER 使能 -pg 選項

FUNCTION_TRACE 即我們常說的 ftrace 功能，ftrace 大大提升了內核的運行時調試能力。ftrace 功能除了 -pg 選項，還要求打開 -mfentry 選項，后者的作用是將函數對 mcount 的調用放到函數的第一條指令處，然后通過 scripts/recordmcount.pl 腳本將該條 call 指令修改為 nop 指令。但 -mfentry 與本文主題沒有關聯，不再細說。

為了驗證這個結論，我們回到上一節的用戶態例子，并且增加了 -pg 編譯選項：“gcc test.c -o test -O2 -pg”，此時運行結果果然正確了。查看其反匯編：

圖6 增加 -pg 選項后的匯編

可以看到，每個函數都有 call mcount 指令，而且 a 函數中將 edi 寄存器保存到 ebx 中，在 newb 函數中又保存 ebx 寄存器。為什么在增加了 call mount 指令后，會做寄存器的保存操作？我們猜想，會不會是因為，由于 call mount 操作相當于調用了一個未知的函數（ mcount 沒有定義在同一個文件中），因此，GCC 認為這樣未知的操作可能會污染了寄存器的數據，所以它才進行了保存現場的操作。

于是我們去掉了 -pg 選項，手動增加了 call mount 的行為進行驗證：在另一個源文件 mcount.c 中增加一個函數 void mcount（） { asm（“nop ”）; }，在 test.c 文件中增加對 mcount 函數的聲明，a 函數中增加對該函數的調用：

extern void mcount（）; //聲明 mcount 函數

static noinline int a（int x）{ int volatile tmp = b（x）; // tmp = 8 ** 3 * 4 mcount（）; return x + tmp; // return 4（not 8） + tmp}

經過編譯：gcc test.c mcount.c -O2 后運行，發現計算結果正確，而且反匯編中 a 函數保存了寄存器：

圖7 調用 mcount 函數后的匯編

繼續驗證猜想，將 mcount 函數放在 test.c 文件中，計算結果錯誤，而且，反匯編中沒有保存寄存器，于是我們得到了這樣的猜想結論：

GCC 在編譯某個源文件時，如果文件內的某個函數（比如場景中的函數 a）調用了其它文件中的一個未知函數（比如場景中的 mcount 函數），則 GCC 會在該函數中保存寄存器；

開啟 -pg 選項，增加了對 mcount 的調用，因此會在函數中增加對寄存器現場的保存操作，對 -O2 選項的函數調用優化起到了屏蔽作用。

神秘的 -fipa-ra 選項：真正的幕后主使

經過我們的探索和資料的查閱，發現了這個 -fipa-ra 選項，可以說它是優化的幕后主使。GCC 手冊中給出 -fipa-ra 選項的解釋是：

Use caller save registers for allocation if those registers are not used by any called function. In that case it is not necessary to save and restore them around calls. This is only possible if called functions are part of same compilation unit as current function and they are compiled before it. Enabled at levels -O2， -O3， -Os， however the option is disabled if generated code will be instrumented for profiling （-p， or -pg） or if callee’s register usage cannot be known exactly （this happens on targets that do not expose prologues and epilogues in RTL）。

這里主要是說，如果開啟這個選項，那么，callee 中如果沒有使用到 caller 使用的寄存器，就沒有必要保存這些寄存器，前提是，callee 與 caller 在同一個編譯單元中而且 callee 函數比 caller 先被編譯，這樣才可能出現前面的優化。如果開啟了 -O2 及以上的編譯優化選項，則會使能 -fipa-ra 選項，然而，如果開啟了 -p 或者 -pg 這些選項，或者，無法明確 callee 所使用的寄存器，-fipa-ra 選項會被禁用。

這段話，其實已經能 cover 掉我們前面大部分猜想的測試驗證：

-O2 選項自動使能 -fipa-ra 進行優化：在我們的場景中，函數 a 使用的 edi 寄存器，在函數 b 中沒有使用到，因此函數 a 被優化，沒有保存 edi 寄存器，但是在 newb 函數中，使用到了 edi 寄存器，且數據被修改，將 newb 函數替換函數 b，則計算結果出錯；

在 -O2 中使用 -pg 選項會禁用 -fipa-ra：編譯時使用 -pg 選項，計算結果是正確的，而且函數 a 保存了 edi 寄存器，說明沒有對函數 a 進行優化；

不在同一編譯單元不會被優化：去掉 -pg 選項，在函數 a 中手動調用 mcount 函數，將這個函數放在 test.c（與函數 a 為同一編譯單元）與放在另一個文件 mcount.c（不同編譯單元）中的計算結果不同：同一編譯單元中計算結果是錯誤的，而且函數 a 沒有保存寄存器現場；不在同一編譯單元中，計算結果是正確的，函數 a（caller） 保存了寄存器現場，因為編譯器無法明確函數 b（callee）所使用的寄存器。

notrace：它是二度沖擊嗎？

用過 ftrace 或者內核開發者應該對 notrace 屬性不陌生，內核中有一些被 notrace 修飾的函數。notrace 其實就是給函數增加 no_instrument_function 屬性。例如，在 X86 的定義：

#define notrace __attribute__（（no_instrument_function））

字面上來看，notrace 和 -pg 的含義可以說完全對立，-pg 讓 jump 變得安全，是否又會在 notrace 上栽一個跟斗呢？幸運的是，我們接下來將看到，notrace 僅僅是禁止了 instrument function，而沒有破壞安全性。

gcc 手冊中的 -pg 選項給出這樣的解釋：

Generate extra code to write profile information suitable for the analysis program prof （for -p） or gprof （for -pg）。 You must use this option when compiling the source files you want data about， and you must also use it when linking. You can use the function attribute no_instrument_function to suppress profiling of individual functions when compiling with these options.

這里主要是說，加上 notrace 屬性的函數，不會產生調用 mcount 的行為，那么，是否意味著不再保護寄存器現場，換句話說，notrace 的出現是否會繞過“-pg 選項對 -fipa-ra 優化的屏蔽”？于是我們又增加 notrace 屬性進行驗證：在 a 函數中增加 notrace 的屬性，因為 a 函數是 caller，編譯時開啟 -pg 選項，然后檢查計算結果及反匯編，最后發現，計算結果正確，而且匯編代碼中保存了寄存器現場。

我們又對所有的函數追加了 notrace 屬性，計算結果正確且寄存器現場被保護。但是這些簡單的驗證不足以證明，于是我們通過閱讀 GCC 源碼發現

通過源碼閱讀，可以確定的是，當使用了 -pg 選項后，會禁用 -fipa-rq 優化選項，GCC 檢查每一個函數的時候都會檢查該選項，如果為 false，則不會對該函數進行優化。

由于 flag_ipa_ra 是一個全局選項，并不是函數粒度的，notrace 也無能為力。因此，這里可以排除對 notrace 的顧慮。

安全性保障：得出結論

經過上述的探索分析以及官方資料的查閱，我們可以得出結論：

內核函數的熱替換，利用 jump 指令直接跳轉到新函數的方式是安全的；

論據：

Linux 遵循的 System V ABI 中的 call conversion 在 x86-64 下有且只有一種；

GCC -fipa-ra 選項會對 call conversion 進行優化，-O2 選項會自動使能該選項，但是 -pg 選項會禁用 -fipa-ra 優化選項；

notrace 屬性無法繞過“ -pg 禁用 -fipa-ra”。

ARM64 下的探索驗證

通過翻閱手冊得知，ARMv8 ABI 中對過程調用時通用寄存器的使用準則如下

Argument registers （X0-X7）

These are used to pass parameters to a function and to return a result. They can be used as scratch registers or as caller-saved register variables that can hold intermediate values within a function， between calls to other functions. The fact that 8 registers are available for passing parameters reduces the need to spill parameters to the stack when compared with AArch32.

Caller-saved temporary registers （X9-X15）

If the caller requires the values in any of these registers to be preserved across a call to another function， the caller must save the affected registers in its own stack frame. They can be modified by the called subroutine without the need to save and restore them before returning to the caller.

Callee-saved registers （X19-X29）

These registers are saved in the callee frame. They can be modified by the called subroutine as long as they are saved and restored before returning.

Registers with a special purpose （X8， X16-X18， X29， X30）

X8 is the indirect result register. This is used to pass the address location of an indirect result， for example， where a function returns a large structure.

X16 and X17 are IP0 and IP1， intra-procedure-call temporary registers. These can be used by call veneers and similar code， or as temporary registers for intermediate values between subroutine calls. They are corruptible by a function. Veneers are small pieces of code which are automatically inserted by the linker， for example when the branch target is out of range of the branch instruction.

X18 is the platform register and is reserved for the use of platform ABIs. This is an additional temporary register on platforms that don‘t assign a special meaning to it.

X29 is the frame pointer register （FP）。

X30 is the link register （LR）。

Figure 9.1 shows the 64-bit X registers. For more information on registers， see 。 For information on floating-point parameters， see Floating-point parameters.

可見，ARMv8 ABI 中對函數調用時的寄存器使用有了明確的規定。

我們對于前面 x86-64 下的探索驗證過程在 arm64 平臺下重新做了測試，相同的代碼和相同的測試過程，得出的結論和 x86-64 下的結論是一致的，即，在 arm64 下，直接利用 jump 指令實現函數替換同樣是安全的。

其它場景的討論

其它語言不能保證其安全性

對于 C 語言而言，在不同的架構和系統下都有固定的 ABI 和 calling conventions，但是其它的語言不能保證，比如 rust 語言，rust 自身并沒有固定的 ABI，比如社區對 rust 定義 ABI 的討論，而且 rustc 編譯器的優化和 gcc 可能會有不同，因此可能也會出現上述 caller/callee-save 寄存器的問題。

kpatch 的真面目

kpatch 利用的是 ftrace 進行函數替換的，它的原理如下所示：

ftrace 的主要作用是用來做 trace 的，會在函數頭部或者尾部 hook 一個函數進行一些額外的處理，這些函數在運行過程中可能會污染被 trace 的函數的寄存器上下文，因此 ftrace 定義了一個 trampoline 進行寄存器的保存和恢復操作（圖11 中的紅框），這樣從 hook 函數回來后，寄存器現場仍然是原來的模樣。

kpatch 用 ftrace 進行函數替換，hook 的函數是 kpatch 中的函數，該函數的作用是修改 regs 中的 ip 字段的值，也就是將新函數的地址給到了 ip 字段，等 trampoline 恢復寄存器現場后，就直接跳轉到新的函數函數去執行了。所以，對于 kpatch 而言，ftrace 的保存和恢復現場操作保護的是 kpatch 中修改 ip 字段函數的過程，而不是它要替換的新函數。

如果修復的是一個熱函數，那么 ftrace 的 trampoline 會對性能產生一定的影響。所以，若考慮到性能的場景，那么使用 jump 指令直接替換函數可以很大的減少額外的性能開銷。

責任編輯：haq