LWN: BPF 中也能panic！

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

The BPF panic function

By Jonathan Corbet
July 18, 2022
DeepL assisted translation
https://lwn.net/Articles/901284/

BPF 子系統(tǒng)的關(guān)鍵賣點之一，就是加載 BPF 程序的動作是安全的：BPF verifier 這個驗證器會在允許加載 BPF 程序之前就確保它不會傷害內(nèi)核。隨著給 BPF 程序賦予了更多的 capability，這種保證也許會變?nèi)趸幢闳绱耍斂吹?Artem Savkov 的這個提議來增加一個讓系統(tǒng) crash 的 BPF helper 的時候，也還是會讓人感到有些驚訝的。如果這個 patch set 能以目前的這種形式合并進來，那么它就會是預示著一個新時代，在這個時代，至少在某些情況下，BPF 程序可以公開地進行破壞性操作。

正如 Savkov 所指出的，BPF 的主要使用場景之一就是用于內(nèi)核調(diào)試，這項任務也經(jīng)常需要在恰當?shù)臅r間生成一個 crash dump 來進行調(diào)試。通過讓 BPF 程序可以使用內(nèi)核的 panic() 函數(shù)，Savkov 就將這兩者結(jié)合了起來，從而允許 BPF 程序在檢測到那些開發(fā)人員正在尋找的問題出現(xiàn)了的特殊情況下直接觸發(fā) crash，并創(chuàng)建 crash dump。Savkov 似乎不是唯一想要這種功能的人；Jiri Olsa 指出，他也收到了關(guān)于這種功能的請求。

將 panic()提供給 BPF 有一些很明顯的危險后果，所以人們期望這里會有一些防護。在這種情況下，首先的防護就是新增的一個 flag，即 BPF_F_DESTRUCTIVE。當加載一個將會調(diào)用破壞性操作（如 panic() 函數(shù)）的程序時，就必須提供這個 flag。如果這個 flag 不存在，BPF 驗證器就會拒絕加載包含調(diào)用任何破壞性 helper 函數(shù)的程序，目前 panic() 是唯一一個。

即使如此，panic() 的 helper 函數(shù)也只對 tracing 程序可用。畢竟，總不應該讓一個紅外解碼器就能讓系統(tǒng) panic 吧，也就是這一限制會阻止人們在 BPF 中實現(xiàn)具有 "panic" 按鈕的遙控器。然后，還有一個新的 sysctl 開關(guān)（kernel.destructive_bpf_enabled）要設置為非零值；否則就將不允許調(diào)用 panic()。即使設置了 sysctl 開關(guān)，代表 BPF 程序運行的進程也必須具有 CAP_SYS_BOOT 這個 capability。

總而言之，BPF 程序似乎不太可能誤操作讓系統(tǒng) panic。

對這個 patch 似乎沒有太多的反對意見，盡管有細節(jié)問題。例如，Song Liu 不喜歡這個 sysctl 開關(guān)，"因為它是全局有效的，用戶很容易忘記用完后把它關(guān)閉掉"。Alexei Starovoitov 也說，在這種情況下不需要 sysctl，CAP_SYS_BOOT 檢查應該就足夠了。Starovoitov 還質(zhì)疑是否有必要讓系統(tǒng)完全 panic，因為有更直接的方法來創(chuàng)建一個 crash dump。Savkov 回答說，panic()是 "更通用的" 做法，而且系統(tǒng)對 panic 的處理動作也是可以由管理員配置的。他確實同意刪除 sysctl 開關(guān)。

Starovoitov 還建議將該功能作為一個 kfunc 而不是 BPF helper 來實現(xiàn)。這里的理由是，kfuncs 被認為是不夠穩(wěn)定的，如果它們被證明是一個壞主意的話可以隨時被刪除，而刪除 BPF helper 則比較困難。當然，值得注意的是，到目前為止，這個關(guān)于 kfuncs 的可移除性的立場還沒有經(jīng)受過憤怒的用戶挑戰(zhàn)（也就是某個用戶的應用程序如果依賴了一個剛剛被移除的 kfunc 時會產(chǎn)生的抱怨）。

在后來的回應中，Starovoitov 質(zhì)疑 panic() 的 "versatility"，并說應該讓 BPF 程序使用更底層的函數(shù)。因此，應該有一個用于創(chuàng)建 crash dump 的函數(shù)，以及一個用于向 console 發(fā)送消息的函數(shù)，一個用于 halt 系統(tǒng)的函數(shù)，一個用于重啟的函數(shù)，等等。他說，這樣一來，BPF 程序本身可以決定應該發(fā)生什么，而不是取決于系統(tǒng)中的具體配置情況。

顯然，這套 patch 的另一個版本將在未來出現(xiàn)，而且它可能看起來與第一次有很大不同。但似乎很明顯，在 BPF 程序中存在這種 "破壞性" 功能的使用場景。BPF 系統(tǒng)正在迅速發(fā)展，已經(jīng)超越了數(shù)據(jù)包處理以及信息收集的范圍，它的發(fā)展方向是把各種內(nèi)核功能都提供給 BPF 程序。目前還不清楚這一切最終會導致什么樣的未來，但很可能會是一個有趣的未來。

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

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