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

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

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

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

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

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