LWN：stable kernel中的bug fix導(dǎo)致專有module的麻煩！
關(guān)注了就能看到更多這么棒的文章哦～
A stable bug fix bites proprietary modules
By Jonathan Corbet
June 21, 2021
DeepL assisted translation
https://lwn.net/Articles/860262/
長久以來，內(nèi)核開發(fā)社區(qū)與那些開發(fā)并發(fā)布專有的（proprietary）loadable module 的公司關(guān)系都很緊張。在許多開發(fā)者看來，這樣的 module 違反了 GPL，應(yīng)該被禁止使用。但這個愿望并未成為現(xiàn)實。相反，社區(qū)一直在追求的處理方法是模糊法律而在技術(shù)上創(chuàng)造不變，從而阻止專有的 module。一個近一年前合入的 "technical-inconvenience" patch 已經(jīng)出現(xiàn)在 stable kernel release 中，已經(jīng)有開發(fā)者（至少一位）抱怨說這個做得有點過了。
直接鏈接到 Linux kernel 的代碼都可以使用它可以看到的任何 symble。而 loadable module 則被限制只能訪問所有 symbol 的一個較小的子集（盡管仍然很大），這個子集中的 symbol 都是明確地 "ecxport" 出來供 module 使用的。用 EXPORT_SYMBOL() 導(dǎo)出的符號對所有 loadable module 來說都是可以使用的，而用 EXPORT_SYMBOL_GPL() 導(dǎo)出的符號則只能供聲明了 GPL 兼容許可證的 module 使用。如果某個不兼容 GPL 的 module 試圖調(diào)用一個只適用于 GPL 的 symbol，那就在 load 的時候就會出錯。
GPL-only 這種 export 方式產(chǎn)生的邏輯是，這類 symbol 都是內(nèi)核中很核心的代碼，使用到這些 symbol 的 module 必須算是內(nèi)核的派生產(chǎn)品（derived product），因此就要遵守 GPL 的要求。在實踐中，大家很少會真的去做這種分析判斷，因而某些 symbol 是否采用 GPL-only export 主要是由開發(fā)者個人決定的。許多開發(fā)者因為非常討厭 proprietary module，因此習(xí)慣性地會把對他們所 export 出來的每一個 symbol 都使用 EXPORT_SYMBOL_GPL()。一些維護(hù)者也鼓勵那些經(jīng)他們之手合入的代碼都采用這種做法。
多年來，proprietary module 的作者們采取了許多技巧來繞過 GPL-only export 的限制。其中之一就是用 kallsyms_lookup_name() 來手動查找 symbol 的地址。這種做法在 2020 年初之后無法再使用了。另一個方法是將一個 module 分成兩個，其中之一是 GPL 許可的，另一個則采用專有的協(xié)議。GPL 許可的 module 直接與內(nèi)核對接，可以在需要的時候使用 GPL-only 的 symbol，然后它再調(diào)用 proprietary module 來完成真正要做的工作。
在 2020 年 7 月，這種跳板功能的 module 在郵件列表中引起了軒然大波，于是 Christoph Hellwig 發(fā)布了一組 patch 來給這種用法增加困難。具體來說，任何調(diào)用了由 proprietary module 所 export 出來的 symbol 的 module，本身都會被標(biāo)記為 proprietary module，無論它向內(nèi)核聲明的許可是什么。因此，那些使用了 proprietary module 的 module 將無法再訪問 GPL-only 的 symbol，這樣一來它們就不可能再完成它的跳板功能了。這個系列在 10 月份的 5.9 內(nèi)核版本中被合并。
當(dāng)時就這么結(jié)束了，直到 2021 年 5 月，這組 patch 被包括在了 5.4.118、4.19.191 和 4.14.233 的眾多更新之中。大概又過了接近一個月，5.4.118 才被某個發(fā)行版所包含，然后讓用戶碰到了問題，這時 Krzysztof Kozlowski 問道，為什么這樣的改動會被包含在一個 stable update 中：
這怎么會算是一個該進(jìn)入 stable kernel 的改動？它修復(fù)了什么具體的、真正困擾人們的 bug 嗎？或者說，它修復(fù)了發(fā)行版中某個 kernel 用戶報告的嚴(yán)重問題了嗎？也就是說，這組 patch 符合 stable kernel 的原有規(guī)則嗎？
它已經(jīng)被證實導(dǎo)致了一些之前已經(jīng)存在的 kernel tree 之外、并且 stable kernel 的有些用戶一直在用的 module 不再可用了。因此，我想知道這里修復(fù)的是什么 bug，這樣破壞現(xiàn)有功能以及打擾 stable kernel 的用戶是否合理。
Stable-kernel 的維護(hù)者 Greg Kroah-Hartman 回應(yīng)說：
它修復(fù)了人們報告出來的一個錯誤，即通過某種方式將 symbol export 出來供那些不應(yīng)該有權(quán)使用的 module 使用了。這個問題在 mainline 和較新的 stable kernel release 中已經(jīng)存在了相當(dāng)長的時間，因此大家也不應(yīng)該想不到它會被進(jìn)一步地 backport 會更老版本的 stable kernel 之中。
討論基本上就這么結(jié)束了，有些人可能會對這個改動進(jìn)入那些舊版本的內(nèi)核感到不那么高興，但不清楚是不是有人真的寄希望于這組 patch 被 revert 掉。不過，可以后續(xù)再觀察一下各個發(fā)行版提供商的內(nèi)核更新，看看他們是會保留這種對 proprietary module 的額外限制呢，還是會悄悄刪除掉，這會很有趣。
不過，這一改動確實說明了 kernel 的 "no regressions" 政策至少有一個限制。這個政策的核心思想是，內(nèi)核的升級不應(yīng)該破壞一個現(xiàn)在能正常運(yùn)行的系統(tǒng)。內(nèi)核開發(fā)者希望用戶能夠有信心來轉(zhuǎn)移到較新版本的內(nèi)核而不用冒一些出錯的風(fēng)險。據(jù) Kozlowski 說，這一改動確實讓一些用戶碰到了麻煩。但是 kernel module 從來未被包括在內(nèi)核的 stability 保證中，就連 GPL-licensed kernel module 也沒有保證穩(wěn)定。當(dāng)某個 proprietary module 碰到麻煩時，內(nèi)核開發(fā)者很少會感到傷心，這次也同樣。
當(dāng) Hellwig 的這組 patch 第一次發(fā)布時，LWN 就注意到它并沒有堵上全部漏洞。具體來說，如果一個 GPL-licensed module 將 symbol 重新包裝一下再 export 給一個 proprietary module 的話，只要并沒有從該 proprietary module 中 import 過 symbol，那么就仍然可以正常工作。這個問題是由 David Laight 在這次討論中也指出了。Kroah-Hartman 回應(yīng)并承諾說："正在努力解決這個問題，預(yù)計會放在下周的一組 patch 之中"。所以，對于開發(fā)和使用 proprietary loadable module 的人來說，后續(xù)可能還會有更多的麻煩。
多年以來內(nèi)核社區(qū)對 loadable module 的策略受到了來自各方的批評。一些人認(rèn)為，哪怕是勉為其難地容忍這些 proprietary module，這也是事實上削弱了 GPL 所提供的保護(hù)，并且是縱容了那些不想按規(guī)則行事的廠商。另一些人則認(rèn)為這是對使用 Linux 的一種障礙，因為它減少了所能支持的硬件，使得用戶需要克服不必要的麻煩。不過，評判這一政策的最好方法是看看過去近三十年來它帶來了什么效果。
目前 proprietary module 仍然存在，但這是少數(shù)情況。大多數(shù)硬件都得到了自由軟件協(xié)議的驅(qū)動程序（free drivers），而且情況似乎還在繼續(xù)改善。過去一些堅持使用 proprietary module 的廠商已經(jīng)找到了方法來改變這種做法。如果這些廠商完全被排除在 Linux 社區(qū)之外的話，可能就不會是現(xiàn)在這種情況了。因此，也許從長遠(yuǎn)來看，可能最有成效的策略仍是讓這些 module 的發(fā)布方過得不太舒服、同時又不去直接禁止它們。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～