基斯·庫克（Kees Cook） 我寫了一篇博文，其中 引起了對錯誤修復過程的擔憂 在 Linux 內核的穩定分支中正在進行，並且是 提到每周大約包括一百次更正 在穩定的分支上，這太多了，需要大量的精力來維護基於 Linux 內核的產品。
根據基斯的說法，內核錯誤處理過程被繞過，並且 內核缺少至少 100 個額外的開發人員 在這方面協調工作。 除了提到主要內核開發人員會定期修復錯誤，但不能保證這些修復會延續到第三方內核變體。
在這樣做時，他提到各種基於 Linux 內核的產品的用戶也無法控制哪些錯誤被修復以及在他們的設備上使用哪個內核。 最終，供應商對其產品的安全性負責，但是面對穩定內核分支上非常高的補丁率，他們面臨著遷移所有補丁、選擇性遷移最重要的補丁或忽略所有補丁的選擇。 .
上游內核開發人員可以修復錯誤，但他們無法控制下游供應商選擇將哪些內容整合到他們的產品中。 最終用戶可以選擇他們的產品，但他們通常無法控制修復哪些錯誤或使用哪個內核（這本身就是一個問題）。 最終，供應商有責任確保其產品核心的安全。
基斯·庫克（Kees Cook） 建議最佳解決方案是僅轉移最重要的修復程序和漏洞，但主要問題是將這些錯誤與一般流程分開，因為大多數新出現的問題是使用 C 語言的結果，在使用內存和指針時需要非常小心。
更糟糕的是，許多潛在的漏洞修復沒有用 CVE 標識符標記，或者在補丁發布一段時間後沒有收到 CVE 標識符。
在這樣的環境中，製造商很難將小修復與主要安全問題分開。 據統計，超過 40% 的漏洞在 CVE 分配前被移除，而從修復發佈到 CVE 分配之間的平均延遲時間為三個月（即在開始時，將解決方案視為常見錯誤，
結果， 沒有單獨的分支來修復漏洞 並且沒有收到關於這個或那個問題的安全性的連接信息， 基於 Linux 內核的產品製造商必須不斷傳輸所有修復程序 新的穩定分支。 但這項工作是勞動密集型的，並且由於擔心可能會破壞產品正常運行的倒退變化而面臨公司的抵制。
鑰匙廚師 認為從長遠來看，以合理的成本保持內核安全的唯一解決方案是重新安置補丁工程師 瘋狂的內核構建l 協同工作 維護上游內核中的補丁和漏洞。 就目前而言，許多供應商不會在其產品中使用最新的內核版本，也不會自行向後移植修復程序，這意味著來自不同公司的工程師會互相複製彼此的工作，以解決相同的問題。
例如，如果 10 家公司，每個公司都有一名支持相同修復程序的工程師，將這些工程師重定向到上游修復錯誤，而不是遷移一個修復程序，他們可以修復 10 個不同的錯誤以獲得整體利益或聚在一起審查錯誤。 . 並避免在內核中包含錯誤代碼。 這些資源還可用於創建新的代碼分析和測試工具，這些工具將在早期自動檢測反復出現的典型錯誤類別。
鑰匙廚師 還建議更積極地使用自動化測試和模糊測試 直接在內核開發過程中，使用持續集成系統，摒棄通過電子郵件進行的陳舊的開發管理。
來源： https://security.googleblog.com