LWN：Intel CPU的間接跳轉(zhuǎn)保護功能！

關(guān)注了就能看到更多這么棒的文章哦～

Indirect branch tracking for Intel CPUs

By Jonathan Corbet
March 31, 2022
DeepL assisted translation
https://lwn.net/Articles/889475/

"Control-flow integrity"（CFI）是一套旨在防止攻擊者改動程序的控制流（control flow）并接管它的技術(shù)。CFI 采用的方法之一被稱為 "間接跳轉(zhuǎn)跟蹤"（IBT, indirect branch tracking），希望能防止攻擊者讓間接跳轉(zhuǎn)（例如，通過指針變量進行的函數(shù)調(diào)用）進入一個不應(yīng)該走到的地方。英特爾處理器的 IBT 功能已經(jīng)開發(fā)了一段時間了。經(jīng)歷了一個突然的轉(zhuǎn)折之后，用 IBT 保護內(nèi)核的功能已經(jīng)被合并到即將發(fā)布的 5.18 版本中。

內(nèi)核也跟許多 C 程序一樣，在廣泛使用 indirect branch 間接跳轉(zhuǎn)。舉一個簡單的例子，來討論一下系統(tǒng)調(diào)用：用戶空間提供了一個數(shù)字，表明需要調(diào)用哪個系統(tǒng)調(diào)用，內(nèi)核通過從表中查找到相應(yīng)的函數(shù)（利用該數(shù)字編號）并通過 indirect branch 來調(diào)用該函數(shù)進行處理。函數(shù)指針在內(nèi)核中比比皆是，其中之一的用途就是用來實現(xiàn)內(nèi)核中類似面向?qū)ο蟮木幊棠Ｐ汀?br>

如果攻擊者能夠以某種方式破壞一個用于 indirect branch 的變量，那么他們可能能夠?qū)?nèi)核的執(zhí)行流程（control flow）重定向到任意位置。這可能會導(dǎo)致意料之外的函數(shù)被調(diào)用了。在像 x86 這樣復(fù)雜的處理器上，也有可能通過跳轉(zhuǎn)到一條多字節(jié)指令的中間位置來獲得特殊效果。有一些攻擊技術(shù)如 return-oriented programming 或者 jump-oriented programming 就依賴這個功能。

IBT 是為了防御面向跳轉(zhuǎn)編程的（jump-oriented programming）；工作原理是試圖確保每個 indirect branch 的目標(biāo)確實都是適合作為跳轉(zhuǎn)目標(biāo)的。IBT 的方法有很多，每一種都有自己的優(yōu)勢和劣勢。例如，內(nèi)核在 5.13 開發(fā)周期中支持了編譯器實現(xiàn)的 IBT 機制。在這種模式下，編譯器通過一個 "jump table, 跳轉(zhuǎn)表" 來完成每一個間接跳轉(zhuǎn)，不僅確保目標(biāo)是要供間接跳轉(zhuǎn)使用的，而且要確保被調(diào)用函數(shù)的原型與調(diào)用者所期望的一致。這種方法是很有效的，但要增加很多編譯、運行時的開銷。

Intel's IBT

英特爾的 IBT 方法相當(dāng)簡單，但優(yōu)點是得到了硬件的支持，因此速度更快。如果 IBT 被啟用，那么 CPU 將確保每個間接跳轉(zhuǎn)都落在一條特殊指令（endbr32 或 endbr64）上，該指令執(zhí)行時跟 no-op 效果一致。如果發(fā)現(xiàn)意外，那么處理器將引發(fā)一次 control-protection（#CP）exception。與上面描述的更完整的方案不同，IBT 不能確保間接跳轉(zhuǎn)的目標(biāo)與調(diào)用者的期望一致，但它可以確保目標(biāo)是同意以間接跳轉(zhuǎn)方式調(diào)用的。

只有當(dāng)間接跳轉(zhuǎn)的每個可能目標(biāo)地址都以 endbr 這種指令開始時，才有開啟這種硬件保護機制的必要。大多數(shù)情況下，這項任務(wù)可以由編譯器完成；GCC（從 GCC 9 開始）和 Clang（從 14 版開始）都實現(xiàn)了-fcf-protection=branch 選項，會在適當(dāng)?shù)臅r候插入插入 endbr 這類指令。不過，這對內(nèi)核中現(xiàn)存的所有匯編代碼并沒有幫助。所以這個 patch set 中大部分的工作都是在需要的地方手動加入 endbr 指令。

當(dāng)內(nèi)核調(diào)用別人的代碼時，還有一個小麻煩，這些代碼可能沒有考慮到 IBT。內(nèi)核并不經(jīng)常調(diào)用外部代碼，但有一個很大的例外就是系統(tǒng)的固件（firmware），它必須經(jīng)常被調(diào)用來執(zhí)行特定的功能。為了安全起見，內(nèi)核會在調(diào)用固件時關(guān)閉 IBT。目前的實現(xiàn)也在將控制權(quán)交給用戶空間時關(guān)閉 IBT。

需要在所有的間接跳轉(zhuǎn)目標(biāo)地址都添加 endbr 指令，這就為今后造成了一個潛在的陷阱：開發(fā)者可能會添加匯編函數(shù)但是忘記了這個指令。如果他們在沒有啟用 IBT 的情況下進行測試，那么這個問題就不會被注意到，可能直到有問題的代碼被合并后的某個讓人非常不爽的時間點才突然暴露出來。為了防止這種情況的發(fā)生，開發(fā)者加強了內(nèi)核的 objtool 工具來檢查所有的間接跳轉(zhuǎn)，并確保所有的目標(biāo)都恰當(dāng)?shù)貥?biāo)注（annotated）好了。

不過，有了這種檢查之后，還可以采取另一個步驟：objtool 還可以列出所有包含 endbr 指令但是永遠不會通過間接跳轉(zhuǎn)到達的函數(shù)。這些函數(shù)不需要進行標(biāo)注，沒有它們的話，內(nèi)核會更安全一些。因此，內(nèi)核 build 的過程會從 objtool 中獲取該列表，并通過用 nop4 指令覆蓋 endbr 來 "封印" 這些函數(shù)。這就減少了攻擊者在啟用 IBT 時仍然可以選擇的攻擊目標(biāo)。

正如 Peter Zijlstra 所指出的，刪除不需要的 endbr 指令還有一個也許是令人驚訝的好處。內(nèi)核限制了 loadable module 所能使用的函數(shù)，而那些專有的（proprietary）module 則受限更多。那些專有的 module 經(jīng)常使用一個技術(shù)就是在內(nèi)核的符號表中查找到它們需要的、未 export 的函數(shù)，然后通過間接跳轉(zhuǎn)來調(diào)用它們，從而繞過內(nèi)核的限制。但是，在啟用 IBT 后，任何缺乏 endbr 指令的函數(shù)都不再能以這種方式調(diào)用了。

An indirect path to the mainline

開發(fā)者已經(jīng)努力了一段時間，希望能讓英特爾 IBT 功能進入 Linux 內(nèi)核。實現(xiàn)這個功能的第一個 patch（針對用戶空間代碼而不是針對內(nèi)核）是由 Yu-cheng Yu 在 2018 年發(fā)布的。然后，這項工作似乎成了那些不斷穿越郵件列表的飛行荷蘭人（flying-Dutchman）patch 之一，從未能夠進入 mainline；第 30 版是 2021 年 8 月發(fā)布的，也沒有達到能夠合并的程度。類似的情況也發(fā)生在了用戶空間的影子堆棧（user-space shadow-stack）patch set 上，在經(jīng)歷多次修訂后，這些 patch 最近被 Rick Edgecombe 接手了。

去年年底，Peter Zijlstra 決定創(chuàng)建一個獨立的英特爾 IBT 實現(xiàn)來保護內(nèi)核本身；第一個版是在去年 11 月發(fā)布的，Zijlstra 顯然是 "在周五晚上/周六早上趕工出來的"。這項工作發(fā)展得很快，3月初發(fā)布的第四個修訂版就是為 5.18 合并的版本了。

這就是目前為止的情況了。從 2020 年底上市的 Tiger Lake 一代開始，英特爾處理器就支持 IBT 了，只支持了內(nèi)核代碼。這并不是一個完美的工具，但它將提高攻擊者攻擊這類系統(tǒng)的門檻。同時，目前還不清楚用戶空間的支持何時（或是否）會進入 mainline 內(nèi)核；到目前為止發(fā)布的 30 個修訂版中，有許多根本沒有收到任何 review 意見。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～