这个问题的答案将提供有关在发布之前如何审查 Linux 内核源代码的见解和参考？
对我来说这个问题特别有趣的方面是：
- 谁以及有多少人审查所提供的代码（即通过拉取请求）？
- 是否存在后门可能未被检测到的变化，特别是考虑到固件斑点？
- 是否使用静态/动态代码分析工具，如果使用，只是为了防止意外错误，还是也防止故意后门植入？
信息：我看过洛可美常见问题解答其中提供了以下相关声明
如何将我的补丁添加到内核中？
(RRR) 根据您的补丁，有多种方法可以将其放入内核。首先是确定您的代码属于哪个维护者（查看 MAINTAINERS 文件）。如果您的补丁只是一个小错误修复并且您确定它是 “显然是正确的”，[...]
[...] 这是另一个重要的一点：列表的一个目的是获取补丁经过同行评审和充分测试。[...]
问题的核心是一些见解，这是什么“显然是正确的”和同行评审（例如谁，有多少人？）。
为了举一个具体的例子，我查看了以下示例提交日志对于分阶段rtl8188euwifi 芯片设备驱动程序，可在以下位置找到/usr/srx/linux/drivers/staging/rtl8188eu：
- 修改文件的提交次数为
[...]/rtl8188eu1560git log --format="%x00%h%n%an%n%cn%n%s" --name-status | tr '\0\n' '\n\0' | grep -a '8188eu' | tee commits | wc -l - 作者人数 190 人
sed 's/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq | wc -l - 提交者数量 12（Al Viro、David S. Miller、Greg Kroah-Hartman、Ingo Molnar、Jeff Kirsher、Jiri Kosina、Johannes Berg、John W. Linville、Kees Cook、Linus Torvalds、Michael S. Tsirkin、Peter P Waskiewicz Jr ）
sed 's/^[^\x00]*\x00//g;s/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq
答案1
谁以及有多少人审查所提供的代码？
一般来说，至少是子系统维护者，通常至少是一两个对补丁的一般主题感兴趣的其他开发人员。例如，安全改进补丁通常会涉及关注安全的开发人员以及正在修改的子系统的维护人员。更复杂的补丁会受到更多关注，除非它们的开发人员无法让任何人对它们感兴趣。引入过多维护成本的补丁不会进入（请参阅这个例子确实是你的）。
后门是否有可能未被检测到，特别是考虑到固件斑点？
根据定义，固件斑点几乎是不透明的，所以是的，后门有可能未被检测到。更一般地说，当您看到某些攻击的复杂性时例如对于网络浏览器，当然可以想象，在许多看似不相关的补丁过程中可能会引入后门。如果看似不相关的补丁最终由不同的开发人员审查和批准，则尤其如此。
是否使用静态/动态代码分析工具，如果使用，只是为了防止意外错误，还是也防止故意后门植入？
据我所知，这不是审查过程的一部分；但有许多小组定期针对内核运行分析工具，并报告和/或修复随后提出的问题。一个例子是Coverity扫描。
这明显是正确的是什么？
这差异很大。补丁是仔细审查（参见这是对一个简单补丁的评论），但是补丁提交者得到的反应可能比预期的要少，特别是因为他们通常不如子系统维护者那么熟悉他们正在更改的代码 - 因此，对作者来说可能感觉复杂的更改可能对维护者来说似乎是显而易见的。内核开发社区还倾向于通过要求将大补丁分成可审查的块来避免“大补丁的宽松审查”综合症，并且通常还要求大补丁集获得更多审查。不幸的是，仔细的评论并不能保证正确性；我的一个补丁被子系统维护者修复了，结果它与一个讨厌的错误合并了！ （最近有一篇关于维护者如何处理自己的补丁的分析，这是相关的。）
当子系统维护者合并树时，补丁也会得到总体审查，一直到主要维护者（Linus、Greg 和各种稳定维护者）。这通常不会导致请求更改，但有时确实会发生。
考虑这一切的社会方面也很重要。知名开发商更容易获得评价；我在软件开发领域的一般经验也表明，知名的开发人员可能会发现他们的补丁受到的审查较少......对于不太知名的开发人员，让知名的审阅者批准您的补丁也可以更容易地进入。一般来说，认识正确的人或依靠正确的努力是有帮助的（例如参加强化活动）。