4 月 20 日，全世界都知道了明尼苏达大学（UMN）进行的一项研究计划，该计划涉及提交有意的错误补丁以纳入 Linux 内核。从那时起，由这项工作产生的一篇论文被撤回了，各种信件来来回回，来自 UMN 的许多补丁被审计。显然，现在是时候对情况进行更新了。

LCTT 译注：明尼苏达大学“伪君子提交”这件事引发了开源和技术社区的很多争议，我们也一直关注此事，本文是 LWN 编辑对事件后继发展的总结和观点。

关于这项研究的论文的撰写并不是最近事件的直接原因；相反，它是由 UMN 的另一位开发者发布的一个源于实验性静态分析工具的错误补丁引起的。这导致内核社区的开发者怀疑，提交故意恶意补丁的工作仍在进行。情况显然不是这样的，但当整个故事变得清晰时，讨论已经全面进行了。

LCTT 译注：提交“实验性静态分析工具的错误补丁”的开发者也是 UMN “伪君子提交”研究团队的成员，只是按该团队的说法，“伪君子提交”研究已经结束，最近引发争议的补丁来自另外一个项目。

老话仍然适用：不应该把那些可以充分解释为无能的东西归结为恶意。

4 月 22 日，Linux 基金会技术顾问委员会（TAB，写作本文的 LWN 编辑是该委员会的成员）发表了一份简短的声明，指出，除其他事项外，最近的补丁似乎是真诚地提交的。同时，Linux 基金会和 TAB 给 UMN 的研究人员发了一封信，概述了应该如何处理这种情况；该信没有公开发布，但 ZDNet 显然从某个地方得到了一份副本。除其他事项外，信中要求完全公开作为 UMN 项目的一部分而发送的错误补丁，并要求撤回这项工作所产生的论文。

作为回应，UMN 的研究人员发布了一封公开信，向社区道歉，几天后又发布了他们作为“伪君子提交”项目的一部分所做工作的总结。总共有五个补丁是从两个 sock-puppet 账户提交的，但其中一个是普通的 bug 修复，被错误地从这个错误的账户发送。在剩下的四个补丁中，其中一个是试图插入一个 bug，但是它本身没插入成功，所以这个补丁实际上是有效的；另外三个（1、2、3）包含真正的 bug，这三个都没有被维护者接受，尽管拒绝的原因不一定是有关的 bug。

LCTT 译注：根据 UMN 团队发布的总结：

• 第一个补丁是以“伪君子提交”而发出的，但是后来实际检查发现实际解决了问题，于是 UMN 团队就没有阻止该补丁被合入。
• 第二个补丁没有合入，但是内核维护者说之前有个别人的类似实现的补丁合并过，后来发现有问题而被别人撤销了。
• 第三个补丁没有合入，内核维护者发现了一个问题而没有接受，但是其实该补丁还有另外一个问题并没有被发现。
• 第四个补丁没有合入，和上一个类似，内核维护者没有发现有意放入的缺陷，而是找到另外的编码问题，因此没有合入。
• 第五个补丁是有效的补丁，但不是这个项目的，使用了错误的邮箱发出的。

论文本身已被撤回，不会按原计划在 5 月提交。希望大家可以认为 UMN 在短期内不会再进行类似的研究了。

LCTT 译注：在原文下面有不少评论认为这个研究方向应该继续下去，只是方式方法需要改善。

补丁的重新审查

UMN 活动引起的关注的一个直接结果是，人们对其开发者失去了信任，加上某些方面希望采取某种惩罚性行动。因此，当整个事件爆发时，首先发生的事情之一是 Greg Kroah-Hartman（GKH）发布了一个由 190 个部分组成的补丁系列，以撤销他能找到的尽可能多的 UMN 的补丁。事实上，这并不是所有的补丁；他提到了另外 68 个需要人工审查的补丁清单，因为它们不容易撤销。

碰巧的是，这些“容易撤销”的补丁也需要人工审查；一旦最初的愤怒过去，就没有什么愿望去恢复那些实际上没有错误的补丁。在过去的一周里，这种审查过程一直在进行，一些开发人员在为之努力。大多数可疑的补丁被证明是可以接受的（即使不是很好），已经从撤销列表中删除了；如果本文作者的计数是正确的，仍有 42 个补丁将被从内核中撤出。

对于这 42 个补丁，撤销背后的原因各不相同。在某些情况下，这些补丁适用于旧的、可能是未使用的驱动程序，而且没有人愿意去适当地审查它们。在其他情况下，其希望实现的变更做得很差，将以更好的方式重新实现。而有些补丁包含了严重的错误；这些肯定需要被恢复（而且一开始就不应该被接受）。

不过，看一下全套的 UMN 补丁，印证了一些我们的早期印象。首先，几乎所有的补丁都解决了某种真正的（即使是晦涩难懂的且难以解决）问题；为之写一个补丁是有理由的。虽然这些补丁中有许多显示出对代码的理解程度很低，因此包含了错误，但似乎其中任何一个修复程序的意图都不大可能是恶意的。

也就是说，“恶意”有多种定义。对一些相关的开发者来说，发布未经验证的实验性静态分析工具的补丁而不披露其性质是一种恶意行为。这是另一种涉及未经同意的人类的实验形式。至少，这是对内核开发社区有效工作所需的信任的一种侵犯。

LCTT 译注：如果研究涉及到人类，为了避免人类受到伤害，需要取得人类同意，这就是研究需要得到 IRB 许可的原因。UMN 认为 “伪君子提交” 不是针对人类的研究，给予了 IRB 免除许可。在这个事件中，有人对 UMN IRB 的意见也很大，而且怀疑 IRB 是否有能力对计算机相关研究给出有效判断。

这 190 个补丁中有 42 个坏补丁，坏补丁比率是 22%。很有可能，对几乎任何一个内核开发者的 190 个补丁进行详细审查，都会发现一些回想起来并不是一个好主意的补丁。但愿这个比率不会接近 22%。但必须说的是，所有这些补丁都被整个内核的子系统维护者所接受，这不是一个好的结果。也许这比最初的“伪君子提交”的研究人员所寻找的结果更有意思。他们故意插入 bug 的努力失败了，但却在无意中增加几十个 bug。

同时，还有一份不能干净地撤销的补丁清单。这个名单还没有公布，但 GKH 是从其中的七个子集开始的。他还指出，TAB 将在所有这些补丁的审计工作完成后公布一份完整的报告。到目前为止，这些补丁中还没有任何一个在主线上被撤销；这似乎有可能在 5.13 合并窗口结束时发生。

吸取的教训

从这一系列事件中得到的关键教训之一显然是：不要把自由软件开发社区作为你的实验性工具的一种免费验证服务。内核开发者很高兴看到新工具的产生，并且 —— 如果这些工具能带来好的结果 —— 就使用它们。他们也会帮助测试这些工具，但他们不太乐意成为缺乏适当审查和解释的工具产生的补丁的接受者。

另一个教训是我们已经知道的：内核维护者（以及许多其他自由软件项目的维护者）工作压力过度，没有时间正确地审查经过他们手中的每一个补丁。因此，他们不得不依赖向他们提交补丁的开发者的可信度。可以说，当这种信任得到妥善建立时，内核开发过程是勉强可持续的；如果通常无法信任进入的补丁时，那么它将无法维持下去。

推论 —— 也是我们已经知道的 —— 是进入内核的代码往往不像我们所想的那样得到很好的审查。我们希望相信每一行被合并的代码都经过了高质量的内核开发人员的仔细审查。有些代码确实得到了这种审查，但不是所有的代码。例如，考虑一下 5.12 开发周期（一个相对较小的周期），它在十周的时间里向内核添加了超过 50 万行的代码。仔细审查 50 万行代码所需的资源将是巨大的，因此，不幸的是，其中许多行在被合并之前只得到了粗略的审查而已。

最后一个教训是，人们可能倾向于认为内核正面临着被具有比 UMN 研究人员所展示的更多技能和资源的行为者插入恶意补丁的可怕风险。这可能是事实，但事情的简单真相是，正规的内核开发者继续以这样的速度插入错误，恶意行为者应该没有什么必要增加更多。2 月份发布的 5.11 内核，到 5.11.17 为止，在稳定更新中已经积累了 2281 个修复。如果我们做一个（过于简单的）假设，即每个修复都会修正一个原始的 5.11 补丁，那么进入 5.11 的补丁中有 16%（到目前为止）被证明是有错误的。这并不比 UMN 补丁的比率好多少。

所以，这也许是我们从整个经历中得到的真正教训：内核处理流程的速度是它最好的属性之一，我们都依赖它来尽可能快地获得功能。但是这种速度可能与严肃的补丁审查和低数量的错误不相容。在一段时间内，我们可能会看到处理变得有点慢，因为维护者觉得有必要更仔细地审查变化，特别是那些来自新的开发人员。但是，如果我们不能将更谨慎的处理流程制度化，我们将继续看到大量的 bug，而这些 bug 是否是故意插入的，其实并不重要。

via: https://lwn.net/SubscriberLink/854645/334317047842b6c3/

作者：Jonathan Corbet 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

正如我们昨天报道的，明尼苏达大学的研究人员被踢出了 Linux 贡献群体，Linux 内核社区撤销了之前他们提交的所有 Linux 内核代码，并且，以后默认拒绝所有来自该大学的内核贡献！

发生了什么？是什么让 Linux 内核社区勃然大怒？

这一切始于 2021 年 4 月 6 日对 Linux 内核的一个看似无辜的补丁。明尼苏达大学的一名博士生（Aditya Pakki）提交了一个一共只修改/增加了两行的小补丁：

Signed-off-by: Aditya Pakki <[email protected]>
---
 net/rds/message.c | 1 +
 net/rds/send.c    | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/rds/message.c b/net/rds/message.c
index 071a261fdaab..90ebcfe5fe3b 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -180,6 +180,7 @@ void rds_message_put(struct rds_message *rm)
         rds_message_purge(rm);
 
         kfree(rm);
+        rm = NULL;
     }
 }
 EXPORT_SYMBOL_GPL(rds_message_put);
diff --git a/net/rds/send.c b/net/rds/send.c
index 985d0b7713ac..fe5264b9d4b3 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head *messages, int status)
 unlock_and_drop:
         spin_unlock_irqrestore(&rm->m_rs_lock, flags);
         rds_message_put(rm);
-        if (was_on_sock)
+        if (was_on_sock && rm)
             rds_message_put(rm);
     }
 

由于这个补丁很简单，而且似乎改善了代码的质量，它最初得到了一些成员的支持，但后来在 4 月 9 日受到了 Eric Dumazet 的质疑。

而在 4 月 19 日，资深的内核贡献者 Al Viro 斥责该贡献者提交了一个“没有修复任何东西的补丁”。他指出了提交垃圾代码补丁的两种可能性：

简单地说，这个补丁要么显示出完全缺乏理解，要么显示出有人不真诚地行事。如果是后者[1]，我可以建议尊敬的社会学家们滚蛋，不要再用故意喷出的排泄物来测试审核者了？

如果你觉得他用词太激烈了，这背后是有原因和历史的。

前不久，明尼苏达大学的博士生 Qiushi Wu 和助理教授 Kangjie Lu（看起来是中国人或华裔？）提交了一篇研究论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》。据之前发布在明尼苏达大学的一篇新闻稿（已被删除），该论文被 2021 年 IEEE 安全与隐私研讨会接受：

CS&E 很荣幸地与大家分享博士生 Qiushi Wu 和助理教授 Kangjie Lu 为即将举行的第 42 届 IEEE 安全与隐私研讨会所撰写的论文。IEEE S&P 是展示计算机安全和电子隐私发展的首要论坛，并将该领域的研究人员和从业人员聚集在一起。

他们的论文《论通过伪装提交在开源软件中隐蔽地引入漏洞的可行性》集中讨论了开源软件的供应链安全。

“这项工作影响深远，”Lu 教授说，“供应链安全已经成为当今的一个重要话题。我们的论文已经引起了安全界和开源社区的极大兴趣。”

Wu 和 Lu 将在 5 月的虚拟会议期间展示他们的研究。

研究人员正在测试通过伪装提交在开源软件中隐蔽引入漏洞的可行性，也就是说，以看似有益的提交实际上引入了其他关键问题。结合最近发生的一些软件供应链攻击事件，看起来这是一篇很有意义的论文，也难怪会被 IEEE 会议接受。

然而，似乎他们选择了 Linux 内核项目来进行他们的实验来完成论文。Al Viro 发现，Aditya Pakki 的“无用补丁”很可能是这项研究的一部分。

对 Aditya Pakki 提交的另外一个补丁：

     }
-    gss_release_msg(gss_msg);
+    if (gss_msg)
+        gss_release_msg(gss_msg);
 }

GKH 警告称，不要浪费内核维护者的时间提交这种补丁，Greg Kroah-Hartman（GKH）是仅次于 Linus Torvalds 的内核项目负责人：

请停止提交已知无效的补丁。你的教授正在玩弄审查程序，以便用一些奇怪的、怪异的方式实现一篇论文。
这是不对的，这是在浪费我们的时间，我们将不得不再次向你的大学报告此事……

显然，这不是唯一引起争议的补丁请求。而 Leon Romanovsky 指出，还有 3 个这样的补丁来自同一个研究人员，并认为这些补丁增加了安全漏洞：

他们故意引入内核错误。昨天，我看了一下从 Aditya 那里接受的 4 个补丁，其中 3 个增加了各种严重的安全 “漏洞”。

面对这些公开抨击，该大学的研究人员 Aditya Pakki 认为自己是受害者，指责内核维护者的态度：

敬请停止胡乱指责，这近乎诽谤。

这些补丁是作为我写的一个新的静态分析器的一部分发送的，它的灵敏度显然不是很高。我发送补丁的目的是希望得到反馈。我们不是 Linux 内核方面的专家，反复发表这些言论让人听了很反感。

显然，这一步错了，但你的先入为主的偏见是如此强烈，你提出的指控毫无根据，这种怀疑也不会带来任何好处。

这种态度不仅让人讨厌，而且对新手和非专家也是一种恐吓，我再也不会发送任何补丁了。

这激怒了 GKH，他说：

你和你的团队，已经公开承认发送了有缺陷的补丁，以了解内核社区对它们的反应，并且发表了一篇基于这项工作的论文。现在你又提交了一系列新的有明显错误的补丁，那么我应该对这样的事情怎么看？

它们显然不是由一个有智慧的静态分析工具创建的，因为它们都是完全不同的模式的结果，而且所有这些显然根本没有修复任何东西。 那么，除了你和你的团队在继续通过发送这种无稽之谈的补丁对内核社区的开发者进行试验之外，我还能想到什么？

……

任何有 C 语言知识的人，只要花几分钟就能看出你提交的文件根本没有任何作用，所以认为一个工具创造了它们，然后你认为它们是一个有效的“修复”，这完全是你的疏忽，而不是我们的疏忽。你才是有错的人，我们的工作不是成为你创造的工具的测试对象。

……

我们的社区不喜欢被实验，也不喜欢通过提交已知的补丁来“测试”，这些补丁要么是故意什么都不做，要么是故意引入错误的。 如果你想做这样的工作，我建议你找一个不同的社区来进行你的实验，这里不欢迎你。

正因为如此，我现在不得不禁止你的大学今后的所有贡献，并撕掉你以前的贡献，因为它们显然是以恶意的方式提交的，目的就是为了造成问题。

随后，GKH 撤销了明尼苏达大学提交的大量补丁，GKH 表示：

我一直想这么做，但最近的事件终于迫使我这么做了。

……

这个小组提交的所有文件都必须从内核树上撤销，并需要再次进行审查，以确定它们是否真的是一个有效的修复。 在这项工作完成之前，请删除这些变更，以确保没有问题被引入代码库。

这个补丁集包含了“简单”的修正，还有 68 个需要人工审查的修正。 其中一些不能被恢复，因为它们已经被恢复了，或者被确定其为无效的后续补丁所修复。这证明这些提交的文件几乎都是错误的。

我将和其他一些内核开发者一起工作，以确定这些还原是否真的是有效的变更，如果是的话，以后会重新正确提交。就目前而言，还是安全为上。

我将通过我的开发树进行，所以维护者们不需要担心这个问题，但他们应该意识到，未来任何从 umn.edu 地址来的人提交的文件应该被默认拒绝，除非确定它实际上是一个有效的修复（即他们提供证据，你可以验证它，但是说真的，为什么要浪费你的时间做那些额外的工作？）

对此，你怎么看？

本文参考信息： lore.kernel.org、news.itsfoss.com。