LWN：針對get_mm_exe_file() 的爭議！
關注了就能看到更多這么棒的文章哦～
A disagreement over get_mm_exe_file()
By Jonathan Corbet
October 18, 2021
DeepL assisted translation
https://lwn.net/Articles/873066/
多年來，關于哪些內(nèi)核符號（kernel symbol）應該被 export 到 loadable module 一直有不小的分歧。通常，這些分歧都是跟 proprietary module 可以獲得那些哪些內(nèi)核功能有關。但有時候其實是關于如何以最佳方式來解決一個問題的分歧。最近關于取消 core kernel 的一個功能的 export 的討論就是一個例子。
眾所周知，loadable module 是在系統(tǒng)啟動后被加載到 core kernel 中的大塊內(nèi)核代碼。大多數(shù) module 是設備驅動，但令人驚訝的是，有許多內(nèi)核功能可以編譯成 module 的形式。內(nèi)核中的代碼可以隨意直接使用通常的 C 語言范圍規(guī)則能訪問到的 symbol，而 loadable module 則受到更多的限制，它們只能使用那些被明確 export 出來的 symbol。在理論上，export 出來的 symbol 接口是受到嚴格管制的。在實踐中，多年來有數(shù)以萬計的 symbol 被 export，并沒有受到很多監(jiān)督限制。事實上，當一個 module 開發(fā)者想要使用一個 core kernel 開發(fā)者不希望 export 的 symbol 時，社區(qū)仍然偶爾會出現(xiàn)爭議。
AMD GPU 開發(fā)者最近遇到了一個問題。雖然許多用戶空間的圖形代碼（user-space graphics code）早已開始轉向來使用 atomic mode-setting API 了，但似乎 Chrome OS 目前只是部分實現(xiàn)了這一轉換工作。如果混合著來使用新、舊兩種 API，Chrome OS 可能會碰到硬件無法配合它的問題。為了防止這種情況發(fā)生，amdgpu 驅動就限制了所有客戶端使用 overlay。Simon Ser 的相關郵件更詳細地描述了這種情況，而且無疑比編者的描述更精確。
這種限制可以使 Chrome OS 能能夠工作，但是這種做法也不必要地對其他那些沒有混用 API 的客戶端施加了限制。為了解決這個問題，Ser 添加了一個 patch，希望調(diào)用 get_mm_exe_file() 來獲取用戶空間正在運行的程序的名稱。如果（也只有在）這個名字是 chrome 的情況下，才會強制限制對 overlay 的使用。這使得 Chrome OS 能夠繼續(xù)以其習慣的方式工作的同時，又給了其他客戶端更多的自由。
Ser 不知道的是，今年 9 月份的時候 Christoph Hellwig 就刪除了這個函數(shù)的 export，使得其無法用在 loadable module 中了。一旦 Ser 的補丁進入 linux-next，那么由于它引用了一個不再被 export 的 symbol，這當然會導致 build 出錯。linux-next 的維護者 Stephen Rothwell 就把這個編譯錯誤報告給了相關維護者。于是，Ser 才意識到他的改法無法在 mainline kernel 中正常工作。
Ser 的第一個反應是詢問 get_mm_exe_file() 是否可以再次被 export 出來，因為 amdgpu 驅動現(xiàn)在在使用它了。Hellwig 明確表示不愿意這樣做。在那封郵件以及隨后的郵件中，Hellwig 的解釋并不是很禮貌，甚至在 Ser 要求改變語氣后也仍是保持原樣。先不考慮這個交流方式的問題，這里其實還是有一個觀點需要大家正視。
為什么內(nèi)核不應該 export get_mm_exe_file()？Hellwig 的觀點是，內(nèi)核代碼不應該根據(jù)在用戶空間運行的程序的名字來改變其行為。這個名字完全在用戶空間的控制之下，無論是出于惡意的原因，還是只是在正常的開發(fā)過程中，它都可能在任何時候隨意改名。除此之外，我們假設 Chrome OS 最終會被 fix，不再以這種方式來混合使用 API，屆時 amdgpu 驅動中的檢查就不再有必要，而且可能確實有害。不過，我們沒有辦法知道這個檢查什么時候可以被取消。因此，這個基于當前運行程序名稱的特殊檢測可能會存在很長時間，遠遠超過它真正有用的時間。
但問題是，改變 amdgpu 驅動的行為將破壞現(xiàn)有的 Chrome OS 系統(tǒng)。根據(jù) Hellwig 的說法，正確的解決方案是要求用戶空間來明確選擇那種不受限制的行為方式。Chrome OS 不會采取這種選擇，它就還可以繼續(xù)正常工作。絕大多數(shù)的活躍的應用程序都可以要求申請取消限制。Ser 不喜歡這個解決方案。"不，我們不能對每一個 uAPI 的濫用都有一個'I_AM_NOT_BROKEN' 的 ioctl。用戶空間檢測已經(jīng)確定是這里最好的行動方案了"。Hellwig 堅持認為，如果一個 API 的改動破壞了用戶空間，唯一正確的解決方案是準備一個新的函數(shù)調(diào)用來啟用這個新的行為。
10 月 14 日，Ser 把 amdgpu tree 中的相關 patch 都 revert 掉了。不過，似乎也沒有提供一個單獨的 API 調(diào)用，相反，原來的 patch 看起來將只會是在 Chrome OS 的 kernel 中合入。這也是解決這個問題的一個合理方案。Chrome OS 的開發(fā)者會知道他們什么時候可以放棄這個 patch，同時，它也不會使 mainline kernel 變得混亂。
這個小插曲展示了對 module 的 export symbol 的控制是如何被用來限制這些 module 可以做什么的，也希望能夠借此來提高整個內(nèi)核代碼庫的質量。在這次的情況下，最終的結果看起來是朝著正確的方向發(fā)展的，盡管通往這個解決方案的道路不那么愉快，這是不必要的。多年來，內(nèi)核項目在維護技術標準和尊重開發(fā)者方面已經(jīng)有了提高，但顯然在這兩方面都還有進步空間。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關注，關注 LWN 深度文章以及開源社區(qū)的各種新近言論～