LWN: 努力實(shí)現(xiàn)對(duì)BPF program簽名驗(yàn)證！

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

Toward signed BPF programs

By Jonathan Corbet
April 22, 2021
DeepL assisted translation
https://lwn.net/Articles/853489/

內(nèi)核的 BPF virtual machine 的用法很多樣，可以將 BPF program 加載到內(nèi)核里從而執(zhí)行大量（并且不斷增加）任務(wù)。不斷增長(zhǎng)的這些 BPF 代碼完全可以被當(dāng)作是內(nèi)核本身的代碼。但是，雖然內(nèi)核可以檢查 loadable module 的簽名并阻止加載那些未正確簽名的 module，但對(duì)于 BPF program 說(shuō)并沒(méi)有這樣的機(jī)制。也就是說(shuō)任何一個(gè)有足夠權(quán)限的進(jìn)程都可以加載 BPF program，只要它能通過(guò) BPF verifier 的檢查就行。人們可能會(huì)想當(dāng)然地認(rèn)為給 BPF 添加簽名檢查是很簡(jiǎn)單的，但是這個(gè)子系統(tǒng)有一些特別的地方，使得事情比人們想象的更有挑戰(zhàn)性。不過(guò)，有一個(gè)可能會(huì)成功的解決方案正在醞釀之中，而正是通過(guò)加載另一個(gè) BPF program 來(lái)實(shí)現(xiàn)的。

loadable kernel module 的存儲(chǔ)格式都是 ELF 格式。每當(dāng)一個(gè) module 被加載時(shí)，內(nèi)核會(huì)解析這個(gè) ELF 格式的文件，做一些必要工作從而使得該 module 可以在內(nèi)核中運(yùn)行起來(lái)。這些工作包括為變量分配內(nèi)存、進(jìn)行重定位（relocation）、解析符號(hào)（resolving symbols）等等。所有這些必要信息都存在于 ELF 文件中。給這個(gè)文件加簽名，實(shí)際上就是對(duì)相關(guān)的數(shù)據(jù)計(jì)算校驗(yàn)和然后對(duì)結(jié)果進(jìn)行簽名。

BPF program 也有類似的需求，但其中這些必要信息的組織方式更加復(fù)雜，甚至有點(diǎn)混亂。代碼本身被編譯成了一個(gè)可執(zhí)行程序，然后被鏈接到一個(gè) loader program 中，這個(gè) loader program 在用戶空間中運(yùn)行，它通過(guò)調(diào)用 bpf() 系統(tǒng)調(diào)用將 BPF program 加載到內(nèi)存中。但是，BPF program 還包含一些數(shù)據(jù)區(qū)域，用來(lái)存放和分配 BPF maps，這些數(shù)據(jù)也需要 relocation（重定位），從而處理不同系統(tǒng)上的相同數(shù)據(jù)的不同的排布（layout）。那些必備的 mapping 在 loader program 中被 "聲明" 為特殊的 ELF section；libbpf 庫(kù)會(huì)找到這些部分并把它們變成更多的 bpf() 調(diào)用。然后，BPF program 本身會(huì)在被加載到內(nèi)核之前先被修改，這樣才能確保它在運(yùn)行起來(lái)后能找到相關(guān)的 map。

這種結(jié)構(gòu)，給對(duì) BPF program 實(shí)現(xiàn)簽名驗(yàn)證機(jī)制帶來(lái)了挑戰(zhàn)。這些 BPF map 是 BPF program 本身的一部分，如果它們沒(méi)有按照預(yù)期建立起來(lái)，BPF program 就可能會(huì)出現(xiàn)各種無(wú)法預(yù)計(jì)的錯(cuò)誤。但是內(nèi)核無(wú)法強(qiáng)制制定 map configuration，因此它無(wú)法確保一個(gè)簽名過(guò)的 BPF program 得到了正確的設(shè)置。此外，修改 BPF program 這個(gè)需求本身就會(huì)破壞簽名驗(yàn)證機(jī)制，畢竟，對(duì) BPF program 的修改正是簽名機(jī)制所要防止的行為。因此，內(nèi)核必須某種程度上來(lái)說(shuō)需要在 BPF program 的加載中做更多的工作才行。

In-kernel BPF loading

我們這些老家伙們會(huì)記得，很久以前，內(nèi)核的 module loader 就是位于 user space 的。在 2.5 開(kāi)發(fā)周期中將其移入內(nèi)核，當(dāng)時(shí)導(dǎo)致了許多麻煩。20 年過(guò)去了，仍然有一些開(kāi)發(fā)者因?yàn)槟菚r(shí)的經(jīng)歷對(duì) Rusty Russell 懷有芥蒂。但這些問(wèn)題早已過(guò)去，內(nèi)核內(nèi)的 loader 也早已不再產(chǎn)生問(wèn)題了。因此，從邏輯上講，人們會(huì)期望將用戶空間的 BPF loader 也移到內(nèi)核中去，這應(yīng)該是一個(gè)明智的做法。

根據(jù) Alexei Starovoitov 在一組新 patch 的封面郵件中所說(shuō)，人們已經(jīng)嘗試了多種方法來(lái)按照這個(gè)方向?qū)崿F(xiàn)，但是"在嘗試了幾個(gè)月的之后，還是拋棄了這種做法"。顯然，有人試圖將 libbpf 移到內(nèi)核中。這個(gè)結(jié)果也并不完全令人意外，因?yàn)檫@么復(fù)雜的代碼放在 kernel 里面并不合適。另一個(gè)想法是創(chuàng)建一種新的可執(zhí)行文件格式，其中會(huì)包含了一系列設(shè)置特定 BPF program 所需的系統(tǒng)調(diào)用。

在實(shí)施第二種方法時(shí)遇到了哪些問(wèn)題，并沒(méi)有得到詳細(xì)說(shuō)明。但是，在 Starovoitov 的 patch set 中所實(shí)現(xiàn)的這個(gè)第三種方法，其實(shí)可以被認(rèn)為是這個(gè)想法的一個(gè)變種。不過(guò)，這里的實(shí)現(xiàn)并不是讓內(nèi)核去挨個(gè)調(diào)用一系列的系統(tǒng)調(diào)用，而是讓 user space 來(lái)加載一個(gè)特殊的 BPF program 完成這項(xiàng)工作。

具體來(lái)說(shuō)，這組 patch set 創(chuàng)建了另一種類型的 BPF program，它的唯一目標(biāo)就是為了執(zhí)行系統(tǒng)調(diào)用。這個(gè) BPF program 將在運(yùn)行它的進(jìn)程的上下文中執(zhí)行，并被限制只允許使用一小部分系統(tǒng)調(diào)用。在這組 patch set 中，只允許了 bpf()和 close()。人們期望利用這個(gè) BPF program 來(lái)執(zhí)行必要的 bpf()調(diào)用，從而 load 并 set up 用戶真正想要運(yùn)行的 BPF program。

這個(gè) "loader program" 通過(guò)觀察 libbpf 做了哪些工作來(lái)加載目標(biāo) BPF program，并捕獲每個(gè)由此產(chǎn)生的 bpf()調(diào)用。然后，將這些 bpf() 調(diào)用都搜集起來(lái)，從而創(chuàng)建出 loader program 來(lái)真正重復(fù)執(zhí)行這些動(dòng)作，這些真正執(zhí)行的動(dòng)作會(huì)在正確的時(shí)間進(jìn)行，由內(nèi)核來(lái)完成。因此，內(nèi)核實(shí)際上還是通過(guò)執(zhí)行一系列封裝好的系統(tǒng)調(diào)用來(lái)加載目標(biāo) program，只是這些動(dòng)作被放到一個(gè) BPF program 里面了。

之前提到的需要修改 BPF program 來(lái)找到正確的 map 的目標(biāo)，也用通常的方式解決了，那就是增加另一個(gè)抽象層。先創(chuàng)建一個(gè)數(shù)組來(lái)放置文件描述符，BPF program 會(huì)通過(guò)該數(shù)組來(lái)引用 BPF map。當(dāng) BPF program 被加載時(shí)，這個(gè)數(shù)組可以被修改為指向那些真正 map 的文件描述符。

Next steps

正如 Starovoitov 在 patch 郵件中所指出的，這組 patch 并不是問(wèn)題的最終完整解決方案，它只是第一步而已，給大家指出解決這個(gè)問(wèn)題的方向。還缺失的一大塊就是 BPF program 所需進(jìn)行的 relocation 動(dòng)作，實(shí)現(xiàn)了這個(gè)之后才能得以不依賴于編譯配置而總能訪問(wèn)到相關(guān)的 structure field。這些 relocation 動(dòng)作也需要修改 BPF program 的 text 段，所以相應(yīng)的解決方案可能也會(huì)比較麻煩。可能需要更多的間接方式，從而帶來(lái)更多性能損失，不過(guò)對(duì)于一些用戶來(lái)說(shuō)，他們可能愿意承受這些損失。

當(dāng)然，還有一個(gè)小問(wèn)題，那就是對(duì) BPF program 進(jìn)行簽名以及檢查，這個(gè)問(wèn)題在這組 patch set 中也沒(méi)有得到解決。簡(jiǎn)單提到一個(gè)想法是構(gòu)造一個(gè)流程讓 BPF 程序被打包到一個(gè)內(nèi)核模塊之內(nèi)，如果確實(shí)是這樣實(shí)現(xiàn)了，那么現(xiàn)有的對(duì) module 簽名的全套流程就也可以直接用于 BPF program 了。

乍一看，BPF loader 是一個(gè)挺復(fù)雜的解決方案。但值得注意的是，這種機(jī)制與用戶空間中所做的事情相差不大。在用戶空間中，運(yùn)行一個(gè)程序通常需要啟動(dòng) ld.so 來(lái)準(zhǔn)備好各種部件，之后才能運(yùn)行該程序。因此，這類解決方案有很好的先例。不過(guò)這種設(shè)計(jì)能否進(jìn)入內(nèi)核 mainline，還有待觀察，畢竟這個(gè)方案剛提出來(lái)不久，還沒(méi)有得到多少 review。

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

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