基斯·库克（Kees Cook） 我写了一篇博文，其中 引起了对错误修复过程的担忧 在 Linux 内核的稳定分支中正在进行，并且是 提到每周大约包括一百次更正 在稳定的分支上，这太多了，需要大量的精力来维护基于 Linux 内核的产品。
根据基斯的说法，内核错误处理过程被绕过，并且 内核缺少至少 100 个额外的开发人员 在这方面协调工作。 还提到主要的内核开发人员会定期修复错误，但不能保证这些修复会延续到第三方内核变体。
在这样做时，他提到各种基于 Linux 内核的产品的用户也无法控制哪些错误被修复以及在他们的设备上使用哪个内核。 最终，供应商负责其产品的安全性，但面对稳定内核分支上非常高的补丁率，他们面临着迁移所有补丁、选择性迁移最重要的补丁或忽略所有补丁的选择。 .
上游内核开发人员可以修复错误，但他们无法控制下游供应商选择将哪些内容整合到他们的产品中。 最终用户可以选择他们的产品，但他们通常无法控制修复哪些错误或使用哪个内核（这本身就是一个问题）。 最终，供应商有责任确保其产品核心的安全。
基斯·库克（Kees Cook） 建议最佳解决方案是仅转移最重要的修复程序和漏洞，但主要问题是将这些错误与一般流程分开，因为大多数新出现的问题是使用 C 语言的结果，在使用内存和指针时需要非常小心。
更糟糕的是，许多潜在的漏洞修复没有用 CVE 标识符标记，或者在补丁发布一段时间后没有收到 CVE 标识符。
在这样的环境中，制造商很难将小修复与主要安全问题分开。 据统计，超过 40% 的漏洞在 CVE 分配前被移除，而从修复发布到 CVE 分配之间的平均延迟时间为三个月（即在开始时，将解决方案视为常见错误，
结果是， 没有单独的分支来修复漏洞 并且没有收到关于这个或那个问题的安全性的连接信息， 基于 Linux 内核的产品制造商必须不断地转移所有修复程序 新的稳定分支。 但这项工作是劳动密集型的，并且由于担心可能会破坏产品正常运行的倒退变化而面临公司的抵制。
钥匙厨师 认为以合理的成本长期保持内核安全的唯一解决方案是移植补丁工程师 疯狂的内核构建l 协同工作 维护上游内核中的补丁和漏洞。 就目前而言，许多供应商并没有在他们的产品中使用最新的内核版本，也没有自行向后移植修复程序，也就是说，事实证明，来自不同公司的工程师相互复制了彼此的工作，解决了同样的问题。
例如，如果 10 家公司，每个公司都有一名支持相同修复程序的工程师，将这些工程师重定向到上游修复错误，而不是迁移一个修复程序，他们可以修复 10 个不同的错误以获得整体利益或聚在一起审查错误。 . 并避免在内核中包含错误代码。 这些资源还可用于创建新的代码分析和测试工具，这些工具将在早期自动检测反复出现的典型错误类别。
钥匙厨师 还建议更积极地使用自动化测试和模糊测试 直接在内核开发过程中，使用持续集成系统，摒弃通过电子邮件进行的陈旧的开发管理。
数据来源： https://security.googleblog.com