Kees Cook 是 kernel.org 前 CSO 和 Ubuntu 安全團隊的負責人，現在為 Google 工作，負責 Android 和 ChromeOS 的安全，他對當前修復內核穩定分支中的錯誤的過程表示擔憂。 每週，穩定分支中都會包含大約一百個修復程序，在關閉接受下一個版本更改的窗口後，它會接近一千個（維護者保留修復程序直到窗口關閉，並且在“-rc1”形成後，他們一次性發布積累的），對於基於Linux內核的維護產品來說，量太大，需要大量的人力。
Keys 表示，處理內核錯誤的過程沒有得到應有的重視，並且內核還缺少至少 100 名額外的開發人員來協調該領域的工作。 核心內核開發人員會定期修復錯誤，但不能保證這些修復將被移植到第三方使用的內核變體中。 基於Linux內核的各種產品的用戶也無法控制哪些bug被修復以及在他們的設備中使用哪個內核。 供應商最終對其產品的安全性負責，但由於穩定內核分支的補丁率非常高，他們面臨著向後移植所有補丁、有選擇地移植最重要的補丁或忽略所有補丁之間的選擇。
最佳解決方案是僅遷移最重要的修復和漏洞，但將此類錯誤與一般流程隔離是主要問題。 彈出的大部分問題都是由於使用C語言造成的，在處理內存和指針時需要非常小心。 更糟糕的是，許多潛在的漏洞修復沒有提供 CVE 標識符，或者在補丁發布後一段時間收到這樣的標識符。 在這種情況下，製造商很難將小修復與重大安全問題區分開來。 據統計，超過40%的漏洞在分配CVE之前就被修復了，補丁發佈到分配CVE之間的平均延遲為三個月（即補丁最初被視為通用補丁）。錯誤，但僅幾個月後，就清楚該漏洞已被修復）。
因此，如果沒有單獨的分支來修復漏洞，也沒有收到有關特定問題的安全連接的信息，基於 Linux 內核的產品製造商只能不斷從新的穩定分支轉移所有修復程序。 但這項工作需要大量勞動力，並且由於擔心回歸性變化會擾亂產品的正常運行而遭到公司的抵制。
回想一下，根據 Linus Torvalds 的說法，所有錯誤都很重要，並且漏洞不應與其他類型的錯誤分開並分配到單獨的更高優先級類別。 這種觀點的解釋是，對於不專門研究安全問題的普通開發人員來說，修復程序與潛在漏洞之間的聯繫並不明顯（對於許多修復程序，只有單獨的審核才能讓您了解它們與安全性相關） ）。 根據 Linus 的說法，負責維護 Linux 發行版上的內核包的團隊中的安全團隊有責任將潛在漏洞與一般補丁流程隔離開來。
Kees Cook 認為，以合理的長期成本保持內核安全的唯一解決方案是，公司讓參與將補丁移植到本地內核構建的工程師協同工作，協調維護上游內核中的補丁和漏洞。 在目前的形式下，許多製造商在其產品中並未使用最新的內核版本，而是自行進行向後移植修復，即事實證明，不同公司的工程師重複彼此的工作，解決同樣的問題。
例如，如果10 家公司，每家都有一名工程師支持相同的修復程序，則將這些工程師重定向到上游修復錯誤，而不是移植單個修復程序，他們可以為了共同利益修復10 個不同的錯誤或加入對擬議更改的審查。防止有錯誤的代碼被包含在內核中。 資源還可以用於創建用於測試和代碼分析的新工具，這將允許在早期階段自動識別反復出現的典型錯誤類別。
Kees Cook 還建議直接在核心開發過程中更積極地使用自動化和模糊測試，使用持續集成系統並放棄通過電子郵件進行陳舊的開發管理。 目前，有效的測試受到以下事實的阻礙：主要測試過程與開發分離並在版本形成之後進行。 Keys 還建議使用更安全的語言（例如 Rust）來減少錯誤。
來源： opennet.ru