Linux 內(nèi)核 “社區(qū)” 對待安全的優(yōu)先級并不高，雖然經(jīng)歷了 2000 年代的多次大規(guī)模漏洞利用事件但并沒有讓 Linus Torvalds 本人改變 "A bug is bug" 的哲學(xué)，由于 Linux 內(nèi)核的安全問題逐漸影響到了 Android 和 IoT 設(shè)備，一次 華盛頓郵報的曝光促使了 KSPP（Linux 內(nèi)核自防護(hù)項目）的成立，KSPP 是由 Linux 基金會旗下的 CII（基礎(chǔ)架構(gòu)聯(lián)盟）管理，其吸納了來自諸多大廠商（Google, RedHat, Intel, ARM 等）的工程師進(jìn)行聯(lián)合工作，可惜的是兩年的時間過去了，KSPP 大多時候只是在重復(fù)的抄襲 PaX/Grsecurity 的各種特性以獲得各自雇主那里的 KPI 和 credit，各種混亂的代碼合并到了 Linux 主線影響了 PaX/Grsecurity 的正常開發(fā)，這也是PaX/Grsecurity 關(guān)閉公開訪問 test patch 的主要原因之一。

最近由 Qualys 曝光的 Stack clash 是一個古老的漏洞利用平面的工程化，這威脅到了幾乎所有類 UNIX 系統(tǒng)（包括 GNU/Linux）的安全，當(dāng) Linux 內(nèi)核 x86 的 maintainer 之一 Andy Lutomirski 問及PaX/Grsecurity 是如何修復(fù)時 Linus 直接回復(fù)了 Grsecurity 是垃圾，有趣的是當(dāng) PaX/Grsecurity 的作者之一 Spender曝光了一些內(nèi)核最近的 silent fix以后Linus 居然 “邀請”PaX team/Spender 直接貢獻(xiàn)代碼到 Linux 內(nèi)核代碼，這是不大可能發(fā)生的，因為今天所謂的內(nèi)核 “社區(qū)” 主要是由一幫大廠商的雇員組成，沒有人有義務(wù)免費的貢獻(xiàn)代碼去幫助那些需要從雇主那里獲得 KPI 的工程師。

更諷刺的是，stack clash 的部分修復(fù)居然來自 PaX/Grsecurity 于 2010 年的代碼，Linus 說 PaX/Grsecurity 是垃圾也等同于打 KSPP 的臉，因為 KSPP 還在繼續(xù)抄襲 PaX/Grsecurity，而針對Linux 內(nèi)核的漏洞利用是否大規(guī)模被惡代使用只是曝光與否的問題。此外，雖然 Stack clash 的 * EMBARGOED" 從開始到現(xiàn)在已經(jīng) 1 個月，但至今CVE-2017-1000370(offset2lib bypass) 仍然未修復(fù)，RedHat 網(wǎng)站上所謂的 "Under Investigation" 只是繼續(xù)等待 Linux 主線內(nèi)核的修復(fù)，或許要讓 Linux 內(nèi)核安全有所改善我們需要更多的 stack clash 和 DirtyCow 持續(xù)曝光。

因為利益的關(guān)系，Linux 基金會對自由軟件社區(qū)和 GPL 已經(jīng)非常不友好，雖然 Greg K-Hartman 一直強調(diào) Linux 基金會是一個非盈利組織，但一個 NGO 的 CEO 為什么有高達(dá) 49 萬美金（2014 財年）的年薪，也沒人知道為什么Greg 本人會有 Google 的郵箱（拿 Linux 基金會和 Google 雙薪水？），Linux 內(nèi)核本來有一次改善安全的機(jī)會，可惜 Linux 基金會的市場 PR 需求搞砸了整件事。HardenedLinux 社區(qū)在這里建議所有的 GNU/Linux 用戶請認(rèn)真重新評估數(shù)據(jù)資產(chǎn)的重要性所對應(yīng)的安全等級。"

匿名網(wǎng)友評論：

Linus 的立場其實很清楚，合并到 Linux mainstream 的代碼必須邏輯拆分（便于各子系統(tǒng)統(tǒng)一維護(hù)）、可閱讀理解、可審計。其中，可審計的要求有兩方面：代碼在版權(quán)上不存在問題；代碼容易理解技術(shù)原理和設(shè)計思路。Linux 現(xiàn)在的內(nèi)核代碼貢獻(xiàn)機(jī)制是長期以來形成的，特別是 commit log 這個環(huán)節(jié)，拆分后的 commit log 描述是技術(shù)上的需要，更是版權(quán)上的需要。了解 commit log 約定的歷史的人，會很清楚為什么這么要求。不了解但感興趣的可以看 SCO v IBM 案之后，在 Linux 內(nèi)核 commit log 中引入 signoff 標(biāo)簽的歷史(https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for 。Linus 的原始郵件沒搜索到，知道的人請補充）。PaX/Grsecurity 一直以來漠視這方面的要求，不拆分 patch（提交的是大 patch），不符合代碼進(jìn)入 Linux mainstream 的約定規(guī)范。相關(guān)維護(hù)者不得不猜測邏輯并拆分相關(guān)代碼，這又被 PaX/Grsecurity 描述為 copy/paste “抄代碼”。PaX/Grsecurity 對 Linux 內(nèi)核維護(hù)方式、對 Linux Foundation 充滿敵意。即使在這次論戰(zhàn)中，Linus 也一貫地表達(dá) PaX/Grsecurity 應(yīng)該拆分代碼以達(dá)成直接貢獻(xiàn) Linux mainstream 的目標(biāo)，避免其他人去猜測實現(xiàn)原理及拆分代碼；而 PaX/Grsecurity 則糾纏于 Linux 中存在各種 bug（包括 Linus 自己引入的 security bug），消極合作甚至不合作。Spender 提到的的 vmappable stack 的 CVE，更是其不合作、看笑話的敵視態(tài)度的體現(xiàn)。一個特性進(jìn)入 Linux mainstream，特別是核心的 vm 管理部分，是需要長時間的反復(fù) RFC (request for comment)，反復(fù)改進(jìn)過程的。不在 RFC 過程中指出問題和改進(jìn)，其“我是對的，我是專家，你們這些Linux maintainer都是傻瓜”的心態(tài)可見一斑。至于 KPI 之說，更是欲加之罪。Linux 發(fā)展到今天，依賴出于興趣的 random contributor 是不夠的，sponsored developer 成為主力是不可避免的。某些代碼代表廠商利益和訴求，但大部分的貢獻(xiàn)是 vendor neutral 的。比如 Google 塞進(jìn)了 binder (Android 需要)，但也貢獻(xiàn)了 TFO (tcp fast open)、lockless listen、BBR(bottleneck bandwidth & rtt) 等相當(dāng)大一批重要的代碼，這些是所有使用者及那些并不貢獻(xiàn)代碼的互聯(lián)網(wǎng)公司都受益的；又比如 livepatch 方面，SUSU/RedHat 扯皮拉筋，政治因素比較多，但項目也一直在前行?！盞SPP 大多時候只是在重復(fù)的抄襲 PaX/Grsecurity 的各種特性以獲得各自雇主那里的 KPI 和 credit，各種混亂的代碼合并到了 Linux 主線影響了 PaX/Grsecurity 的正常開發(fā)“，這個困境并不是 Linus 及 Linux Foundation 愿意的，但 Pax/Grsecurity 顯然不想正常方式解決，只想內(nèi)核維護(hù)者屈服和放棄原則。