To be or Not to be - Linux社区禁止一所美国大学提交代码事件

June 30, 2021 by

王永雷

最近 Linux 社区发生的事件

Greg Kroah-Hartman 是一名 Linux 内核主线分支的维护者，2021 年 4 月 22 日发布了一个申明，禁止一所美国大学试图以研究名义故意提交带有安全隐患和其他“实验”性质的可疑代码合并到 Linux 内核主线分支。因此，不再欢迎来自明尼苏达大学为上游 Linux 内核开发做出贡献。在后续消息中，确证了之前明尼苏达大学（University of Minnesota）对 Linux 内核的补丁将被还原。

事情的起因

明尼苏达大学计算机科学与工程系刘教授领导的安全研究小组，主要研究和教授系统安全相关的课程。主要研究安全性，操作系统，程序分析和编译器的交叉点。刘教授的研究旨在以有原则和实用的方式保护广泛使用的系统和基础软件（例如 OS 内核和编译器）的安全-发现新的漏洞和威胁类别，检测安全漏洞，并保护软件系统免受攻击，他的工作导致流行的系统（如 Linux 内核，Android OS 和 Apple 的 iOS）进行了许多更新。

事件的发生顺序简述如下：

1. 刘教授小组的学生 Aditya Pakki 向 Linux 内核提交了补丁

2. Linux 内核的维护人员发现这些布丁没有太大意义，所以回信说不会合并代码

3. Aditya Pakki 觉得有些委屈，觉得社区不是很友好 Linux 内核人员 Greg KroahHartman 于是找出了之前刘教授小组提交的论文 On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits（基于伪装技术向开源代码中引入漏洞），并认为这个事件为了研究论文而故意提交恶意代码，觉得不太厚道，所以发文禁止明尼苏达大学向 Linux 提交任何代码

4. 4 月 21 日，明尼苏达大学发表官方申明，将会立即终止此项研究，同时针对学校批准此项研究的过程，采取适当的补救措施，防止将来发生类似事件，同时尽快将进一步的调查报告给社区。

https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021

5. 于此同时，哥伦比亚大学教授 Sean P. Goggins 也声援明尼苏达大学，认为老师们都是很好的人。

6. Linux 社区的领袖 Linus 对此表示了不满：“这很让人讨厌，因为大部分的补丁是有用的（通常补丁不是”无用的”或者“故意提交恶意代码”），所以从根本上来说，这种行为就是在浪费大家的时间。”

7. 刘教授的 Tiwtter 在 4 月 21 号发表声明，解释了 Aditya 现在在研究补丁中的缺陷，他不是故意去做这件事情的

8. 我们会继续关注 Linux 社区的进一步的反馈

各方观点

从新闻报告此次事情的起因如下：Stemming from this research paper where researchers from the University of Minnesota intentionally worked to stealthy introduce vulnerabilities into the mainline Linux kernel. They intentionally introduced use-after-free bugs into the kernel covertly for their research paper.

Greg Kroah-Hartman 认为明尼苏达大学的研究人员故意在此研究论文中隐瞒将漏洞引入主线 Linux 内核的观点。他们有意在研究论文中秘密地将 Use-After-Free 漏洞引入内核。

But even after this paper, there has been a new round of patches from University of Minnesota researchers that claim to come from "a new static analyzer" but without any real value to the patches. These new, questionable patches don't appear to have any real value -- for good or bad -- and at the very least are just wasting time by upstream developers. This has led Greg to calling them out and "banning" them from trying to contribute to the Linux kernel in the future.

但是，即使在本文发表之后，明尼苏达大学的研究人员也进行了新一轮补丁修补，声称它们来自“新型静态分析工具”，但补丁没有任何实际价值。这些新的，可疑的补丁似乎没有任何真正的价值,不论是好是坏-,至少是在浪费上游开发者的时间。这导致 Greg 告知他们，并“禁止”他们将来尝试对 Linux 内核做出贡献。

Greg wrote this morning on the kernel mailing list, "[These new patches] obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?...A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create...Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems."

Greg 今天早上在内核邮件列表中写道：“ [这些新补丁]显然是由具有任何智能的静态分析工具创建的，因为它们都是完全不同的模式的结果，而且显然所有这些模式甚至都没有修复所有问题。那么，除了您和您的团队正在通过发送此类无意义的补丁继续在内核社区开发人员上进行实验之外，我应该怎么想？可以看到您的提交根本不做任何事情，因此认为工具创建了它们，然后您认为它们是有效的“修复”，这完全是您的责任，而不是我们的责任。成为您创建的工具的测试对象不是我们的工作...因此，我现在必须禁止您的大学将来所有的贡献，并清除您以前的贡献，因为它们显然是以不良的方式提交的，意图引起错误的导向。”

So those from the University of Minnesota are no longer welcome to contribute to the upstream Linux kernel development.

因此，不再欢迎来自明尼苏达大学的人员为上游 Linux 内核开发做出贡献。

In a follow up message is indeed confirmation that the prior University of Minnesota patches to the Linux kernel are going to be reverted.

在后续消息中，确实的确证了明尼苏达大学（University of Minnesota）对 Linux 内核的先前补丁将被还原。

通过阅读明尼苏达大学的论文刘教授的论文，其中第八页最后一段关于道德考量A. Ethical ConsiderationsEnsuring the safety of the experiment. In the experiment, we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not tointroduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code. In addition to the minor patches that introduce UAF conditions, we also prepare the correct patches for fixing the minor issues. We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time windowbetween the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our correct patch. In all the three cases, maintainers explicitly acknowledgedand confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected.

道德考量为了确保实验的安全。在实验中我们旨在证明通过隐秘的伪装提交的漏洞。我们的目标不是引入漏洞来损害 OSS。因此，我们安全的进行实验以确保引入的 UAF 错误将不会合并到实际的 Linux 代码中。此外对于介绍 UAF 条件的小补丁，我们还准备了的补丁程序以解决这些问题。我们通过电子邮件将次要补丁发送到 Linux 社区寻求他们的反馈。幸运的是，有一个时间窗口在补丁确认与合并之间修补。维护人员确认我们的补丁后，例如一封电子邮件表示“看起来不错”的回复，我们会立即通知的 UAF 的维护者，并要求他们不要继续应用补丁。同时，我们指出错误的正确修复，并提供我们正确的补丁。在这三种情况下，维护者都明确承认并确认不会继续使用不正确的补丁程序。所有引入 UAF 的补丁程序仅保留在电子邮件中交换，甚至没有在 Linux 中成为 Git 提交分支机构。因此，我们确保没有任何介绍 UAF 错误曾经合并到 Linux 内核的任何分支中，并且没有 Linux 用户会受到影响。

论文的作者的出发点和思考点是针对开源代码通过伪装进入到开源社区的风险，

关于 IRB（Institutional Review board)伦理审查委员(以下内容来自:

https://zhidao.baidu.com/question/363146061580767892）

IRB 是为了确保有责任地科研的一种预防监督机制。IRB 的初衷针对有人类受试者参与的科学试验进行的伦理审核，因此设立 IRB 的逻辑是：科技的进步需要试验，这种试验一般由三方组成：科研人员、社会大环境以及受试者。科研的初衷自然是希望对大家都有益，但怎么才算“有益”，不能仅凭这三方中的任何一方之言；而且由于科研的专业性，使得科学试验在科研-社会-受试个人之间存在信息不平衡，因此就需要有个比较可靠的群体，能够对每一项试验进行审核，以确保最大限度平衡不同利益方以及社会的短期/长期利益。

由此建立了 IRB，因此 IRB 审核虽然因项目不同而不同，但一般一定会出现三个问题：1）这个试验有什么风险，这个风险是否被充分告知利益相关人（比如受试者）2）是否已规避了所有不必要的风险，且不可避免风险是否被合理地降低到最低，以及相关科研团体是否采取了合理的保护措施（比如给受试者上保险）3）权衡试验预期的价值，是否其社会意义利大于弊，对试验个人是否公正。现实中，IRB 的 approval 一般需在科研工作者向基金会提出各种 grant application 之前获得——也就是说，想申请钱，先说明这个试验构想是否具有社会责任感和基本职业道德。

因为 IRB 和科研基金申请（以及后来可能出现的科研纠纷）有直接的关系，IRB 一般归类为高校的科研管理部门（research administration），成员一般是“兼职”，一般会有熟悉 paperwork 后勤 administrator/院系领导，学科专业人员、法学人员等等——具体成员因学校和学科而异

论文中提到涉及到 IRB 审批的部分

Regarding potential human research concerns. This ex- periment studies issues with the patching process instead of individual behaviors, and we do not collect any personal information. We send the emails to the Linux community and seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter.The experiment will not collect any personal data, individual behaviors, or personal opinions. It is limited to studying the patching process OSS communities follow, instead of individ- uals. All of these emails are sent to the communities instead of individuals. We also prevent the linkage to maintainers. In particular, to protect the maintainers from being searched, we use a random email account, and three cases presented

关于潜在的人类研究关注。本实验研究修补过程中的问题，而不是个人行为，并且我们不收集任何个人信息。我们将电子邮件发送给 Linux 社区，并寻求他们的反馈。实验不是要责怪任何维护者，而是要揭露过程中存在问题。明尼苏达大学的 IRB 审查了实验程序，并确定这不是人类研究。我们获得了一份正式的 IRB 豁免函。

实验不会收集任何个人数据，个人行为或个人意见。它仅限于研究 OSS 社区遵循的补丁程序，而不是个人。所有这些电子邮件都发送给社区，而不是个人。我们还阻止与维护者的联系。特别是，为了保护维护者免遭搜索，我们使用了一个随机电子邮件帐户

明尼苏达大学的官方针对此事的官方回复如下：

Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical.

明尼苏达大学计算机科学与工程学系的领导今天了解到其一位教职员工和研究生正在研究 Linux 内核的安全性的详细信息。所使用的研究方法引起了 Linux Kernel 社区的严重关注，从今天开始，这已导致该大学被禁止为 Linux Kernel 做出贡献。

学校非常重视这种情况。立即中止了这一研究。学校将调查该研究方法和批准该研究方法的过程，并采取适当的补救措施，该措施防止将来发生相似的问题。我们将尽快将调查的结果报告给社区。

评论 —— 几点启发：

第一点 Linus Law 还有效么

多眼原则对安全漏洞还有效么，著名的 Linus Law 原则提到说，只要有足够多的眼睛，代码的 bug 自然而然的重现，但是现有的机制真的能够保证我们不引入有安全问题的代码吗？我们如何保证，目前看起来这个 case 是有效的，当 Linux 核心代码库的人员在检查这些代码的时候，确实有发现这些提交的代码是无效的，同时引起了社区的注意，但是这个前提是这些代码库的维护人员都是非常专业和资深的人员，但是如果社区比较新，代码检查人员没有那么有经验的话，是否在代码提交之前用自动化的程序扫描一次，或者入库之前扫描一次是个选择么，另外针对故意隐藏的安全缺陷的代码我们有一些好的解决方案可以避免吗？这个值得我们我们去思考。

第二点科学研究的价值（来自于庄表伟的讨论）

建议去查看所有历史上，已经发生的各次 code review，然后评价这些 code review 的过程，是否确实排查出问题，还是可能已经漏过了问题。然后去证明：仅仅通过人工的检查，是不足以拦截的。如果一个 bug 已经被引入社区，又是花了多少时间，才会被发现，最后被修复的，这些分析过去发生的历史的研究，再加上跨社区的对比，其实能够得到更加有价值的结论，这些是值得我们去研究的方向

第三点道德的底线，IRB 的价值

做有道德的事情，这个是我们应该遵守的基本的底线

第四点建立信任很难，打破信任很容易

第五点如何从社区维护的角度去帮助社区维护者减少工作量，如果能够集合 AI 和 ML 等去建模，更加智能的去判断一些安全漏洞，我觉得比较有意义，这样可以大幅度的减少维护者的审核的工作量，这样的研究是不是更有意义一些

*本文图片来源网络，如有侵权请联系删除！

参考资料

https://www.phoronix.com/scan.php?page=news_item&px=University-Ban-From-Linux-Dev

https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/

https://www.zdnet.com/article/greg-kroah-hartman-bans-university-of-minnesota-from-linux-development-for-deliberately-buggy-patches/

https://www-users.cs.umn.edu/~kjlu/

https://mp.weixin.qq.com/s/1RHpMGc9uCTglfSnXQfZGQ

https://twitter.com/kengiter/with_repliesOpenSourceInsecurity(1).pdf

原文2021年4月28日发表于公众号「开源社」，作者：王永雷

事情的起因各方观点评论 —— 几点启发：

in 技术博客

# Linux Law 代码安全漏洞社区维护