LWN: kernel中GCC plugin的未來(lái)命運(yùn)！
關(guān)注了就能看到更多這么棒的文章哦～
The future of GCC plugins in the kernel
April 1, 2021
This article was contributed by Marta Rybczyńska
DeepL assisted translation
https://lwn.net/Articles/851090/
內(nèi)核加固（kernel hardening）的流程可以在多方面受益于編譯器支持。近年來(lái)，內(nèi)核自我保護(hù)項(xiàng)目（Kernel Self Protection Project）將 grsecurity/PaX 中的一些 patch set 以 GCC plugin 的形式來(lái)給 kernel 提供了更多支持。LWN 早在 2017 年就報(bào)道過(guò)這個(gè)流程。最近的一次討論中重點(diǎn)講述了這樣一個(gè)事實(shí)：使用 GCC plugin 方式也帶來(lái)了一些缺點(diǎn)，一些開(kāi)發(fā)者希望能看到后續(xù)用其他方式取代這些插件。
討論來(lái)源于 Josh Poimboeuf 的報(bào)告，他在啟用 GCC 插件編譯 kernel tree 之外的 module 時(shí)遇到一個(gè)問(wèn)題。在他的場(chǎng)景中，只要用來(lái)編譯 module 的 GCC 版本與用來(lái)構(gòu)建 kernel 的版本稍有不同時(shí)，編譯就會(huì)失敗。他附上了一個(gè) patch，用來(lái)將 error 改為 warning，并禁用了受影響的 GCC 插件。稍后，Justin Forbes 解釋了一下這個(gè)導(dǎo)致問(wèn)題的環(huán)境是如何產(chǎn)生的：這發(fā)生于 Fedora 的持續(xù)集成系統(tǒng)中，該系統(tǒng)會(huì)先從建立一個(gè)當(dāng)前的 toolchain snapshot 來(lái)開(kāi)始。然后用新的 toolchain 來(lái)編譯 kernel tree 之外的 module，而不會(huì)重新編譯 kernel 本身。自從 GCC plugin 被啟用后，所有帶有 kernel tre 之外 module 的編譯 job 都會(huì)失敗。
將 error 改為 warning 的想法，在內(nèi)核構(gòu)建系統(tǒng)維護(hù)者 Masahiro Yamada 看來(lái)不是很贊同，他說(shuō)："我們有一個(gè)假設(shè)，就是 kernel tree 之內(nèi)和之外的代碼都應(yīng)該是用同一個(gè)編譯器編譯的"。Poimboeuf 回應(yīng)說(shuō)，現(xiàn)實(shí)世界中的的情況并不是這樣的。不過(guò)，其他內(nèi)核開(kāi)發(fā)者也同意 Yamada 的觀點(diǎn)。Greg Kroah-Hartman 寫道：
你難道沒(méi)有注意到 include/linux/compiler.h 以及我們?yōu)楦鞣N不同版本的 gcc/clang/intel 等編譯器所做的那些各不相同改動(dòng)以及 workaround 嗎？我們從來(lái)沒(méi)有保證過(guò)用不同的編譯器所編譯出來(lái)的 kernel module 能夠工作，我認(rèn)為我們現(xiàn)在也不應(yīng)該開(kāi)始改變這個(gè)觀點(diǎn)。
此外，Yamada 指出，在以前的討論中，對(duì)內(nèi)核及其 module 的編譯會(huì)使用相同的編譯器版本，這已被接受為一種潛在規(guī)定。由于內(nèi)核開(kāi)發(fā)者明確表示了不同意，所以討論似乎已經(jīng)結(jié)束。
The dislike for GCC plugins
然而，Poimboeuf 幾天后帶著另一個(gè)可以解決他的問(wèn)題的方案回來(lái)時(shí)，討論又重新開(kāi)始了，這個(gè)方案是：每當(dāng) GCC 版本改變時(shí)，就重新編譯所有的 plugin。這被 Yamada 拒絕了，他指出 Ubuntu 并沒(méi)有 GCC 版本不匹配的問(wèn)題，所以這個(gè)問(wèn)題似乎是 Fedora 特有的。Linus Torvalds 也不同意這個(gè)提議，但是因?yàn)榱硪粋€(gè)原因。對(duì)他來(lái)說(shuō)，當(dāng) GCC 版本改變時(shí)，并沒(méi)有什么出于技術(shù)上的限制會(huì)需要人們必須重新編譯更多的東西，但他對(duì) GCC 插件的一些通用使用和設(shè)計(jì)方面表示了關(guān)注。在后續(xù)的郵件中，他用了比較強(qiáng)烈的語(yǔ)言解釋了他的理由：
內(nèi)核的 GCC 插件最終 會(huì) 消失。它們是一場(chǎng)無(wú)妄之災(zāi)。一直都是這樣。我很抱歉我曾經(jīng)合并了這些功能進(jìn) kernel。它不僅對(duì)于維護(hù)工作是個(gè)噩夢(mèng)，而且它首先本身就是一個(gè)可怕的東西，帶著很不好用的 interface。這個(gè)技術(shù)簡(jiǎn)直太糟糕了。
對(duì)于 Torvalds 來(lái)說(shuō)，如果要正確實(shí)現(xiàn)這種插件，就應(yīng)該是在中間表示法（IR，intermediate representation）這一層來(lái)進(jìn)行修改，但是 GCC 的插件由于一些非技術(shù)性的原因而被設(shè)計(jì)成用其他方式實(shí)現(xiàn)了（主要是擔(dān)心 non-free 插件，也就是非自由軟件的插件，LWN 在 2008 年就報(bào)道過(guò)這一點(diǎn)）。他說(shuō)，對(duì)插件感興趣的人應(yīng)該使用 Clang，因?yàn)樗幸粋€(gè)干凈的 IR，并且很容易允許在 IR 級(jí)別添加類似的檢查。
GCC plugins and their Clang equivalents
然而，刪除內(nèi)核里 GCC 插件這件事，似乎在近期并不可能實(shí)現(xiàn)。Kees Cook 介紹了 GCC 插件的現(xiàn)狀、它們?cè)?Clang 中的等價(jià)功能、以及為什么其中一些插件會(huì)有個(gè)用戶社區(qū)。GCC 插件提供的一些功能還不能用 Clang 來(lái)實(shí)現(xiàn)，其實(shí)無(wú)論如何，很多發(fā)行版提供商都沒(méi)有使用 Clang 來(lái)構(gòu)建內(nèi)核。
目前內(nèi)核支持以下插件（位于 scripts/gcc-plugins/）：
cyc_complexity，計(jì)算函數(shù)的循環(huán)復(fù)雜性。它是兩個(gè)最初的示例插件之一，可能并沒(méi)有用戶。
latent_entropy 增加了 CPU 執(zhí)行時(shí)的熵。Cook 認(rèn)為沒(méi)有什么地方用到它，特別是在增加了抖動(dòng)熵機(jī)制之后。后續(xù)沒(méi)有計(jì)劃在 Clang 中支持這個(gè)。
arm32 的各個(gè)任務(wù)堆棧保護(hù)器（per-task stack protector for arm32）為 32 位 ARM 平臺(tái)提供了堆棧保護(hù)。Cook 說(shuō)，目前 Clang 連 64 位系統(tǒng)都還沒(méi)有對(duì)應(yīng)的功能。
randstruct 隨機(jī)地改變內(nèi)核數(shù)據(jù)結(jié)構(gòu)中各個(gè)字段的順序，這只對(duì)那些只包含函數(shù)指針的結(jié)構(gòu)生效，或者那些明確用__randomize_layout 標(biāo)記過(guò)的結(jié)構(gòu)生效。這個(gè)插件有兩個(gè)版本：一個(gè)是完整版，一個(gè)是限制版。限制版只會(huì)改變同一 cacheline 中的多個(gè)成員之間的順序，這降低了性能開(kāi)銷，但也降低了保護(hù)水平。Clang 中有一個(gè)版本已經(jīng)被提出來(lái)了，但目前被擱置。Cook 指出，有安全意識(shí)的那些最終用戶都傾向于啟用這個(gè)插件，但發(fā)行版提供商通常不啟用。
sancov（Cook 沒(méi)有提到）會(huì)通過(guò)在每個(gè) basic block 的開(kāi)始插入一個(gè)對(duì)__sanitizer_cov_trace_pc()的調(diào)用，來(lái)幫助那些 fuzzing coverage 測(cè)試，也就是用來(lái)確定哪些代碼塊真正得到了利用。
stackleak 會(huì)追蹤內(nèi)核里的堆棧深度，以便在返回用戶空間時(shí)可以用特定模式的內(nèi)容來(lái)覆蓋掉已使用過(guò)的堆棧。目前還沒(méi)有計(jì)劃支持 Clang。
structleak 初始化了那些可能會(huì)被傳遞給用戶空間的結(jié)構(gòu)。Clang 的 -ftrivial-auto-var-init=zero 選項(xiàng)就是類似實(shí)現(xiàn)。GCC 后續(xù)可能也會(huì)支持該選項(xiàng)。
最終的結(jié)果看來(lái)，這些插件還是繼續(xù)存在一段時(shí)間的。
同時(shí)，討論中也有一些積極的成果。在這個(gè)過(guò)程中我們意識(shí)到，這些插件對(duì)它們所對(duì)應(yīng)的 GCC 版本非常敏感，每當(dāng) GCC 版本發(fā)生變化時(shí)，它們并沒(méi)有被重新編譯過(guò)。顯然，自從插件第一次被添加以來(lái)就是這個(gè)情況了；盡管 Yamada 在討論中拒絕了這個(gè)想法，但他還是解決了這個(gè)問(wèn)題。作為 Poimboeuf 最初問(wèn)題的解決方案，開(kāi)發(fā)者們最終同意在內(nèi)核和模塊之間出現(xiàn) GCC 版本不匹配時(shí)顯示一個(gè)警告。這將由用戶來(lái)決定這個(gè)差異可可以忽略的，還是需要重新編譯內(nèi)核。
GCC 版本不匹配的問(wèn)題并不是 Poimboeuf 注意到的唯一一個(gè)問(wèn)題；他還指出了插件構(gòu)建系統(tǒng)對(duì)一個(gè) gcc-plugin-devel 包（可選的）的依賴關(guān)系。即使用戶的 GCC 版本與編譯內(nèi)核時(shí)使用的版本相同，但如果他們沒(méi)有這個(gè)包，插件也會(huì)被悄悄地禁用，而內(nèi)核編譯會(huì)成功完成且沒(méi)有任何警告。這個(gè)問(wèn)題還沒(méi)有得到進(jìn)一步解決。
Conclusions
這次討論涵蓋了 GCC 插件的一些問(wèn)題。這很可能意味著開(kāi)發(fā)者在啟用它們時(shí)應(yīng)該小心謹(jǐn)慎。Poimboeuf 最初的問(wèn)題利用這個(gè) warning 就得到了某種程度的解決，這個(gè) warning 可能開(kāi)始在一些系統(tǒng)中報(bào)告出來(lái)。如果兩個(gè) GCC 版本很接近的話，用戶可能會(huì)選擇忽略這個(gè) warning。在啟用插件時(shí)，開(kāi)發(fā)者應(yīng)該注意先安裝 gcc-plugin-devel，否則他們的 module 可能并沒(méi)有按照你的要求來(lái)完成編譯。
內(nèi)核中的 GCC 插件的未來(lái)尚未決定。Clang 似乎是 hardening 工作的首選，這個(gè)方向也得到了 Torvalds 的鼓勵(lì)，但是現(xiàn)有的各個(gè) GCC 插件（除了一個(gè)以外）并沒(méi)有 Clang 的對(duì)應(yīng)物。看來(lái)，它們至少還會(huì)存在一段時(shí)間。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長(zhǎng)按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開(kāi)源社區(qū)的各種新近言論～