Kees Cook 是 kernel.org 的前首席系统管理员，也是 Ubuntu 安全团队的负责人，现在在 Google 工作，负责 Android 和 ChromeOS 的安全，他对当前修复内核稳定分支中的错误的过程表示担忧。 每周，稳定分支中都会包含大约一百个修复程序，而在下一个版本接受更改的窗口关闭后，它会接近一千个（维护者保留修复程序直到窗口关闭，并在形成“ -rc1”他们一次性发布了累积的），对于基于Linux内核的维护产品来说，这个数量太多并且需要大量的人力。
Keys 表示，处理内核错误的过程没有得到应有的重视，并且内核还缺少至少 100 名额外的开发人员来协调该领域的工作。 主要内核开发人员定期修复错误，但不能保证这些修复将转移到第三方使用的内核变体。 基于Linux内核的各种产品的用户也无法控制哪些bug被修复以及在他们的设备中使用哪个内核。 最终，制造商对其产品的安全性负责，但由于在稳定内核分支中发布修复程序的强度非常高，他们面临着一个选择：移植所有修复程序，有选择地移植最重要的修复程序，或者忽略所有修复程序。
最佳解决方案是仅迁移最重要的修复和漏洞，但将此类错误与一般流程隔离是主要问题。 出现的最大数量的问题是使用 C 语言造成的，在使用内存和指针时需要非常小心。 更糟糕的是，许多潜在的漏洞补丁没有提供 CVE 标识符，或者在补丁发布后一段时间被分配了 CVE 标识符。 在这样的环境中，制造商很难将小修复与重要的安全问题分开。 据统计，超过 40% 的漏洞在分配 CVE 之前就得到了修复，并且修复发布与 CVE 分配之间的平均延迟为三个月（即修复最初被认为是一个常规错误，但仅在几个月后就清楚该漏洞已被修复）。
因此，如果没有单独的分支来修复漏洞，也没有收到有关特定问题的安全连接的信息，基于 Linux 内核的产品制造商只能不断地从最新的稳定分支转移所有修复程序。 但这项工作需要大量劳动力，并且由于担心出现倒退性变化而扰乱产品的正常运行，因此面临公司的阻力。
让我们回想一下，根据 Linus Torvalds 的说法，所有错误都很重要，并且漏洞不应与其他类型的错误分开并分配到单独的更高优先级类别。 这种观点的解释是，对于不专门研究安全问题的普通开发人员来说，修复程序与潜在漏洞之间的联系并不明显（对于许多修复程序，只有单独的审核才能了解它们涉及安全性） ）。 根据 Linus 的说法，负责维护 Linux 发行版中内核包的团队的安全专家应该参与从常规补丁流中识别潜在漏洞。
Kees Cook 认为，以合理的长期成本维护内核安全的唯一解决方案是，公司将参与将修复程序移植到本地内核构建的工程师转移到联合、协调的工作中，以维护主内核（上游）中的修复程序和漏洞。 ）。 在目前的形式下，许多制造商在其产品中并未使用最新的内核版本，而是在内部向后移植修复程序，即事实证明，不同公司的工程师重复彼此的工作，解决同样的问题。
例如，如果 10 家公司，每家都有一名工程师向后移植相同的修复程序，重新分配这些工程师来修复上游的错误，那么他们可以为了共同利益修复 10 个不同的错误，而不是向后移植一个修复程序，或者加入对提议的审查。更改并防止有错误的代码包含在内核中。 还可以将资源用于创建用于测试和分析代码的新工具，以便及早发现反复出现的常见错误类别。
Kees Cook 还建议在内核开发过程中更积极地直接使用自动化和模糊测试，使用持续集成系统并放弃通过电子邮件进行陈旧的开发管理。 目前，有效的测试受到以下事实的阻碍：主要测试过程与开发分离并在版本形成之后进行。 Keys还建议在开发时使用提供更高级别安全性的语言，例如Rust，以减少错误数量。
来源： opennet.ru