任何涉及到human research的审核都比较繁琐, 有serious ethical ramifications 现在状况是教授说他的研究属于non-human research 范畴（他实验做完，paper写完后才跟IRB申请允许，IRB同意这是non-human research)。但主楼里第三个链接针对IRB guidelines/exceptions一一做了分析，认为这个教授的研究不符合任何exemptions（总而言之，所有人都觉得他的研究有serious abuse)。 其中一人的总结推测 That leaves the authors to either pursue full IRB review for their work (as a full IRB review can approve a deceptive research project if it deems it appropriate and the risk/benefit balance is in favor to the participants) or to self-certify as non-human subjects research and fix any problems later. They decided to go with the latter. 另外，楼中也有一个人提到他被当作小白鼠的经历，有人回复IRB有时候为了善后也会偏袒研究者，但是如果human小白鼠比较坚持自己的利益，其实是有standing的。
Regarding potential human research concerns. This experiment 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. 他们的研究就是揭露Linux open source code review process 有安全隐患。对公司不厚道，但作为独立研究学校是认可的。商学院也有类似的研究，发现有些公司数据有问题。只不过公司会施加压力，不让发表。
Regarding potential human research concerns. This experiment 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. 他们的研究就是揭露Linux open source code review process 有安全隐患。对公司不厚道，但作为独立研究学校是认可的。商学院也有类似的研究，发现有些公司数据有问题。只不过公司会施加压力，不让发表。 hellokitty00 发表于 2021-04-22 08:58
Regarding potential human research concerns. This experiment 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. 他们的研究就是揭露Linux open source code review process 有安全隐患。对公司不厚道，但作为独立研究学校是认可的。商学院也有类似的研究，发现有些公司数据有问题。只不过公司会施加压力，不让发表。 hellokitty00 发表于 2021-04-22 08:58
IRB审核的是biomedical research involving human subjects， 审核的结果也只是说不是human research。
我去追了一下原thread，相当有意思—— I don't think the attack described in the paper actually succeeded at all, and in fact the paper doesn't seem to claim that it did. Specifically, I think the three malicious patches described in the paper are: - UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.... The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn't actually appear to constitute a vulnerability because pci_disable_device() doesn't appear to free the struct pci_dev. - UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... This patch was not accepted. - UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.... Same author as case 1. This patch was not accepted. This is not to say that open-source security is not a concern, but IMO the paper is deliberately misleading in an attempt to overstate its contributions. 换言之，这教授发的三个假commit，其中一个并不会真正造成教授说的问题，另外两个在review之后压根没被accept。所以，教授发文章吹牛逼，把学校给坑进去了？……
Regarding potential human research concerns. This experiment 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. 他们的研究就是揭露Linux open source code review process 有安全隐患。对公司不厚道，但作为独立研究学校是认可的。商学院也有类似的研究，发现有些公司数据有问题。只不过公司会施加压力，不让发表。 hellokitty00 发表于 2021-04-22 08:58
这什么情况？这属实吗？没有经过IRB批准根本不能开始research。如果开始了也不能发表。我还第一次听说这种也能补票的。 miaka 发表于 2021-04-22 00:27:16
昨晚爬了Twitter, 这是你好奇的来龙去脉, 以及某一方的看法 Sarah Jamie Lewis I see that we are talking about "Hypocrite Commits" again and I want to clarify a few things. Despite what their paper says they didn''''t get an IRB-exemption until *after* they posted about their IEEESP paper acceptance and a group of researchers (inc myself) expressed concern... Thread 很长 https://twitter.com/SarahJamieLewis/status/1384871385537908736?s=19
回复 271楼phlin的帖子 我觉得这个事情甚至会毁了他和这个学生在美国工业界的机会。 至少如果我听说我的雇主hire了这个人我会raise a concern。no one in the software industry wants to be on the enemy side of the Linux community。
因为到现在为止，大家都是以good faith的真诚来提交代码。 而从现在开始，大家明白了，有很多not in good faith的人也会来提交代码。所有人都看到这个问题，所有的“坏人”也都看到了这个问题，这将造成future成千万倍的工作量的增长。 比如我是个高中生，我现在明白了，我可以毫无顾忌地去submit代码，你们reviewer就去996吧。 比如我是个黑客，我现在明白了，原来我可以写一段看似安全，但是恰好我能利用的代码，累死你们reviewer. 你们公司几个reviewer能干什么？这可是全世界数量级的submit.
Sarah Jamie Lewis@SarahJamieLewis I see that we are talking about "Hypocrite Commits" again and I want to clarify a few things. Despite what their paper says they didn't get an IRB-exemption until *after* they posted about their IEEESP paper acceptance and a group of researchers (inc myself) expressed concern... 认为IRB没有很好履行义务 Sarah Jamie Lewis@SarahJamieLewis · Apr 21 They lied to people in order to assess their response, with no system in place for prior informed consent or debriefing. That any IRB could conclude that it wasn't a deception study on human subjects speaks to the overall ability of many IRBs to reason about internet studies. 高亮作者两篇文章中改动之处 （作者淡化后果） I also want to take a moment to point out the original wording of their abstract (in their screenshot IEEESP announcement) v.s. the paper published in that repository. "successfully introduced multiple exploitable...vulnerabilities" v.s. "safely demonstrate it is practical" 不认为文章有实用价值 （作者给linux oss其中一个建议，就是未来contributor要多加一句：我不会故意在代码中写bug) > "but they still did demonstrate a flaw" It was a known flaw, one practically every maintainer is aware of. The solution is safer languages with stronger security semantics coupled with automated testing and analysis tools. Initiatives that many people are actively working on. 最后，这位女士的总结 Anyway this is the latest in a long line of computer science researchers stumbling into human subject research, disregarding any and all ethical considerations, getting a paper published, and leaving to find a new community fuck around in.
Sarah Jamie Lewis@SarahJamieLewis I see that we are talking about "Hypocrite Commits" again and I want to clarify a few things. Despite what their paper says they didn't get an IRB-exemption until *after* they posted about their IEEESP paper acceptance and a group of researchers (inc myself) expressed concern... 认为IRB没有很好履行义务 Sarah Jamie Lewis@SarahJamieLewis · Apr 21 They lied to people in order to assess their response, with no system in place for prior informed consent or debriefing. That any IRB could conclude that it wasn't a deception study on human subjects speaks to the overall ability of many IRBs to reason about internet studies. 高亮作者两篇文章中改动之处 （作者淡化后果） I also want to take a moment to point out the original wording of their abstract (in their screenshot IEEESP announcement) v.s. the paper published in that repository. "successfully introduced multiple exploitable...vulnerabilities" v.s. "safely demonstrate it is practical" 不认为文章有实用价值 （作者给linux oss其中一个建议，就是未来contributor要多加一句：我不会故意在代码中写bug) > "but they still did demonstrate a flaw" It was a known flaw, one practically every maintainer is aware of. The solution is safer languages with stronger security semantics coupled with automated testing and analysis tools. Initiatives that many people are actively working on. 最后，这位女士的总结 Anyway this is the latest in a long line of computer science researchers stumbling into human subject research, disregarding any and all ethical considerations, getting a paper published, and leaving to find a new community fuck around in. urthur 发表于 2021-04-22 13:24
回复 363楼might的帖子 对的，这对于reviewer而言就是标准的DDoS。 话说他们那些垃圾代码review request乍一看还挺像模像样的，譬如这个—— On Mon, Aug 10, 2020 at 07:16:48AM +0200, Jiri Slaby wrote: > On 10. 08. 20, 0:14, James Bond wrote: > > Syzkaller find a memory leak in con_insert_unipair: > > BUG: memory leak > > unreferenced object 0xffff88804893d100 (size 256): > > comm "syz-executor.3", pid 16154, jiffies 4295043307 (age 2392.340s) > > hex dump (first 32 bytes): > > 80 af 88 4e 80 88 ff ff 00 a8 88 4e 80 88 ff ff ...N.......N.... > > 80 ad 88 4e 80 88 ff ff 00 aa 88 4e 80 88 ff ff ...N.......N.... > > backtrace: > > [<00000000f76ff1de>] kmalloc include/linux/slab.h:555 [inline] > > [<00000000f76ff1de>] kmalloc_array include/linux/slab.h:596 [inline] > > [<00000000f76ff1de>] con_insert_unipair+0x9e/0x1a0 drivers/tty/vt/consolemap.c:482 > > [<000000002f1ad7da>] con_set_unimap+0x244/0x2a0 drivers/tty/vt/consolemap.c:595 > > [<0000000046ccb106>] do_unimap_ioctl drivers/tty/vt/vt_ioctl.c:297 [inline] > > [<0000000046ccb106>] vt_ioctl+0x863/0x12f0 drivers/tty/vt/vt_ioctl.c:1018 > > [<00000000db1577ff>] tty_ioctl+0x4cd/0xa30 drivers/tty/tty_io.c:2656 > > [<00000000e5cdf5ed>] vfs_ioctl fs/ioctl.c:48 [inline] > > [<00000000e5cdf5ed>] ksys_ioctl+0xa6/0xd0 fs/ioctl.c:753 > > [<00000000fb4aa12c>] __do_sys_ioctl fs/ioctl.c:762 [inline] > > [<00000000fb4aa12c>] __se_sys_ioctl fs/ioctl.c:760 [inline] > > [<00000000fb4aa12c>] __x64_sys_ioctl+0x1a/0x20 fs/ioctl.c:760 > > [<00000000f561f260>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:384 > > [<0000000056206928>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: leak checking failed > > > > To fix this issue, we need to release the pointer p1 when the call of > > the function kmalloc_array fail. > > This reminds me of: > commit 15b3cd8ef46ad1b100e0d3c7e38774f330726820 > Author: Ben Hutchings <[email protected]> > Date: Tue Jun 4 19:00:39 2019 +0100 > > Revert "consolemap: Fix a memory leaking bug in > drivers/tty/vt/consolemap.c" > > This reverts commit 84ecc2f6eb1cb12e6d44818f94fa49b50f06e6ac. > > > > So NACK. I have a whole talk just about the "fun" involved with that change: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ > Do we have some annotations for this instead? We need something there, a comment saying "this is fine, don't touch it!" or something like that? We need that in a few other places in the vt code as well. > > Signed-off-by: James Bond <[email protected]> Nice name... James, can you mark this syzbot report as "invalid" or something like that please so that this does not come up again and again. thanks, greg k-h 这个SA工具是真的有，至于它是不是真的报告了这个问题就不知道了。然后reviewer们还在很认真地讨论，你这么修反倒会造成问题，之前就有类似的commit被revert，咱们是不是该在这里加个注释，不要动这一段代码…… linux内核的源代码可读性看来的确不行，所以review起来可想而知耗时耗力。不过这算是open source代码的通病了，freebsd也没好哪去，我的前公司就是在freebsd的基础上开发产品的，涉及freebsd内核的代码每每看得我想死。
12月的申明里没说赦免。再说哪有IRB Wavie一说，不需要IRB approval的直接被拒，IRB Office根本不予审核。你这又是从哪来的消息。
https://www.zhihu.com/question/455914876/answer/1848439222
华人上还没理清头绪，国内论坛倒是热火朝天…
那如果
實驗者來不及把毒藥丸抽走
或者 有人看到 上華人要了源代碼 另外找途徑把毒藥丸送上去
或者 實驗室新進人員 把 毒藥丸跟 一般的藥丸 一起重新送上去
這樣的風險
有評估過嗎?
任何涉及到human research的审核都比较繁琐, 有serious ethical ramifications
现在状况是教授说他的研究属于non-human research 范畴（他实验做完，paper写完后才跟IRB申请允许，IRB同意这是non-human research)。但主楼里第三个链接针对IRB guidelines/exceptions一一做了分析，认为这个教授的研究不符合任何exemptions（总而言之，所有人都觉得他的研究有serious abuse)。
其中一人的总结推测
That leaves the authors to either pursue full IRB review for their work (as a full IRB review can approve a deceptive research project if it deems it appropriate and the risk/benefit balance is in favor to the participants) or to self-certify as non-human subjects research and fix any problems later. They decided to go with the latter.
另外，楼中也有一个人提到他被当作小白鼠的经历，有人回复IRB有时候为了善后也会偏袒研究者，但是如果human小白鼠比较坚持自己的利益，其实是有standing的。
整個操作
說穿了就是
駭客的嘗試
而且是對不知情的第三方做測試
那如果你黑入了銀行的 ATM
讓ATM吐出了錢 但最後沒把錢拿走
如果對方是個 銀行
會不會把這張提款卡
或整個帳戶
列為拒絕往來戶?
我其实不清楚，不是专家。 学校应该也会从各种technicalities上去分析 ，毕竟这个项目据说已经过了IRB审核，文章又被IEEE symposium接受。不过教授是AP，如果真有些不妥，学校会愿意保他吗？Linux foundation如果不愿意撤掉针对大学的ban又如何？
海外华人什么时候没有这种带入感，就真正融入，落地生根了！
IRB 說是跟人體實驗無關 駭客也無關啊 symposium 審稿沒那麼 detail
鬧出這種事 tenure 應該是拿不到了 校方告到法院去除 ban 也不佔理
畢竟有惡意的存在 除非把這人給開除了 也就是惡意的去除
Signed-off-by: Aditya Pakki <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[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 92b6b22884d4..ed1d2255ce5a 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; 这里是函数最后一行了，你set rm 为NULL 有什么用？ } } EXPORT_SYMBOL_GPL(rds_message_put); diff --git a/net/rds/send.c b/net/rds/send.c index 68e2bdb08fd0..aa3bc081773f 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) 指针rm这里肯定不能是NULL，否则前面就挂了。指针rm的值又不能被上面的函数改变，你这里加个判断也没有任何意义 + if (was_on_sock && rm) rds_message_put(rm); }
redhat是linux foundation的孙子好吧，open source开发测试好了红帽才好打包起来拿去卖钱 他惹恼了kernel的维护者，redhat恨不死他。
不懂不要瞎说 开源项目都是免费的，作为一个顶级的开源项目，linux kernel利好了多少公司高校和个人研究者。人家又不靠这东西卖钱，code review当然重要，但要这群天才花数十倍的时间去对付这种屡教不改的恶意测试，简直就是拖科技进步的后腿。你要测试，光明正大写个proposal，设计一个被大家认可的测试方案再开始很难么？非要搞些偷鸡摸狗的事情。
拉倒吧。我自己也是apache某infra项目的commitee成员。原来我们都是天才啊，飘了飘了
叫这些人技术官僚可能更合适。
飘吧飘吧，不过这两个OSS不在一个级别上。
一个普通的开源项目好意思跟linux kernel的commitee比，然后自己说自己是天才。。。脸厚如此。
这个阿三跟发表的论文是一个课题组的，光看发表论文不想想正在准备的manuscript？
您这是受了改名贴多大刺激以至于耿耿于怀至此呀？ 学术界大部分人都不改名的
只要排除
惡意的文化團體來的人
就行了
搞软件正劲是非常需要ethics的
比如怎么保护客户隐私，开不开后门，各种操作是否合规，etc
https://twitter.com/kengiter/status/1330649966214340608
看不起华人大妈？人民群众的眼睛都是雪亮的。
陪审团还特意要选这些平凡的大爷大妈呢。
没有bug的代码，估计只有hello world。这声明不像理工科写的，没有逻辑。
好比銀行如果要 駭客來做安全測試
那是經過銀行的同意與委託
不然就是駭客攻擊了
他们的研究就是揭露Linux open source code review process 有安全隐患。对公司不厚道，但作为独立研究学校是认可的。商学院也有类似的研究，发现有些公司数据有问题。只不过公司会施加压力，不让发表。
iOS is not based on Linux though. It has the same source as macOS which is based on BSD.
被质疑了，就辩解说反正没死人，没有造成伤害。
对呀。 一堆人什么都喷。
IRB审核的是biomedical research involving human subjects， 审核的结果也只是说不是human research。
I don't think the attack described in the paper actually succeeded at all, and in fact the paper doesn't seem to claim that it did. Specifically, I think the three malicious patches described in the paper are: - UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.... The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn't actually appear to constitute a vulnerability because pci_disable_device() doesn't appear to free the struct pci_dev. - UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... This patch was not accepted. - UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.... Same author as case 1. This patch was not accepted. This is not to say that open-source security is not a concern, but IMO the paper is deliberately misleading in an attempt to overstate its contributions.
换言之，这教授发的三个假commit，其中一个并不会真正造成教授说的问题，另外两个在review之后压根没被accept。所以，教授发文章吹牛逼，把学校给坑进去了？……
这个报道不准确吧。 这个学者提交有bug的代码到代码库是测试代码库能不能检测出bug，是正常的工作 （单元测试或者集成测试是每个开源代码库提交必须通过的步骤，他的说法是站得住脚的）。 不过我也没有读完整的报告，不知道其他地方是不是出错。
没办法，偏偏这么多无耻小人
open source的安全性就是很重要。世上坏人多了去了，你没法控制什么人contribute, 不是免费提供就可以出任何问题都免责的。这也是为什么组织私人捐赠的食物，人家基本只收罐头，因为出了事就是组织人责任。
那三个bug，其中一个不能造成教授说的损害，另外两个是废代码，都有真人review，然后就没有accept。所以我觉得SA或者是sanity test查不出来正常，特别是后两个，review都过不了还谈何测试。
那些review的人还挺认真的，还给垃圾代码的作者解释为啥你认为可以修的问题压根不会出现。我也能理解他们发现自己原来是浪费时间在垃圾上头有多恼火。
所以你要是给了有问题的食物，被抓住了就终身禁止捐赠，这没毛病
至于漏洞，人家自己过后当然会fix，并不能改变你恶意投毒的性质
对啊，不是human research，所以不会以反人类罪起诉他而已
这种专业的东西 你还是少评论吧
我觉得他的工作还是很有意义的 open source 是有测试 和 review 过程， 他的工作就是对这个过程的测试而已 测试这个过程的严密程度，让大家对问题的现实有所认识没有什么不好
这和投毒没有什么相似之处，提交的东西不会造成立即的伤害， 而且他在测试过后就提交 paper公开了，自然也就fix了，也不会造成以后的伤害
昨晚爬了Twitter, 这是你好奇的来龙去脉, 以及某一方的看法
Sarah Jamie Lewis
I see that we are talking about "Hypocrite Commits" again and I want to clarify a few things.
Despite what their paper says they didn''''t get an IRB-exemption until *after* they posted about their IEEESP paper acceptance and a group of researchers (inc myself) expressed concern...
Thread 很长 https://twitter.com/SarahJamieLewis/status/1384871385537908736?s=19
很多人看问题就喜欢感情用事。发现揭露企业的问题研究不违法，不管是什么动机。外部监管有社会性益处。就像钓鱼执法，知假打假一样。如果不属实，公司自然会去告他，如果属实，加强内部管理就是了。
这个在市场机制下很常见。
我觉得这个事情甚至会毁了他和这个学生在美国工业界的机会。 至少如果我听说我的雇主hire了这个人我会raise a concern。no one in the software industry wants to be on the enemy side of the Linux community。
软体很可怕的。
linux这种软件，有些老bug可以导致billion 级别的全球loss。
比起有可能引发的global outage，他这点意义可以忽略不计。
从这人提交的code来看，他自己水平有限，造出来的bug自己都未必控制得了，还是算了吧。
而且测试有测试的流程，他这样是故意不遵守流程的
你连警察都不是，钓鱼执法不就成了用私刑了，这还不犯法？
这就是欺负这个组织。
你怎么不化妆成危险分子去应聘国土安全部呢。
是啊，只要不构成刑事犯罪的事情就可以做。
那还要不要讲学术道德了？没人让他去坐牢，但是足以葬送自己的学术生涯了。
你这个没有常识的就别洗了，自己拿三两瓶水都不满，洗得让人觉得你父母是不是应该一头撞死生出这么个没道德的小人
把个人行为用于给所有国内来的人分类？你们独运轮和1450也是疯了
其实从以上观点可以推断出来开源就会走向闭源。
比如楼上说开源的安全性很重要，世界上的坏人多。但因为有这些坏人，开源组织又没有这么多的精力来维护安全性和可靠性，所以干脆就不开源了。
没有精力LINUX如何进化到现在？ 我们公司也有KERNEL开源的REVIEWER 开源才能最大的保证代码的安全性
长得死蠢，做的事情更是奇蠢无比，没看出哪里斯文了
就是这个意思。 比如6一个好区，大家都是落地玻璃门对着后院，都很漂亮。一个z做防盗门的公司过来起敲碎人家的玻璃门，然后说，我不是要偷东西哈，就是给大家看看这玻璃门多不安全。来装完我的防盗门吧！我也是好心。 差不多这个意思。 楼里辩护的就是，他不去砸门，玻璃门就安全吗？是吧。
因为到现在为止，大家都是以good faith的真诚来提交代码。
而从现在开始，大家明白了，有很多not in good faith的人也会来提交代码。所有人都看到这个问题，所有的“坏人”也都看到了这个问题，这将造成future成千万倍的工作量的增长。
比如我是个高中生，我现在明白了，我可以毫无顾忌地去submit代码，你们reviewer就去996吧。 比如我是个黑客，我现在明白了，原来我可以写一段看似安全，但是恰好我能利用的代码，累死你们reviewer.
你们公司几个reviewer能干什么？这可是全世界数量级的submit.
還是得等
刁 方的洗地文
才能跟上啊 要不然 小醬又得
彎道摔車 了
美國參議院要每年拿 兩億美元出來跟 刁 對玩大外宣了
刁方的大外宣人員 少抽個 0.2%就有了
编程话题下的优秀答主
谢邀@杨微粒 569 人赞同了该回答 求死作死然后真死了，有什么委屈的。
没有维护过大型软件的可能不知道引入一个bug能有多可怕。 简单说吧，一个bug可能引起七八种不同的故障表现；逆着故障追查可能会找到十几种不同的“原因”——显然的，这些原因绝大多数是错的（甚至可能全都是错的）——错误修改了不是原因的原因，就可能在抑制一个错误现象的同时引入另外五六个奇怪的故障；为了修复这些故障，又造成了一堆新的bug……层层“转包”之后，可能整个系统就不再能够维护了。 你看，一旦“病从口入”、一旦被劣质开发者越改越糟，这套软件往往就可以放弃了——重新写一套说不定还便宜点。
因此，当你加入一家较为正规的公司、第一次修改bug时，那些老同事们往往就如临大敌，不得不一次次问你：你真的找到这个错误的root cause了吗？请证明你找到的是root cause……请证明除了root cause，其它错误不可能引起同样的故障…… 总之，经过很多轮的“审问”，你的patch才会被评审者接受，才可以合入软件仓库、进入测试流程……
随着你合入代码次数越来越多、且一直没有引起bug（或者很少引起bug），对你的“审问”就会越来越轻松——这是因为代码评审也是非常非常消耗精力的事情：为了合入三行代码，评审者很可能不得不参考前后超过五百行代码，这才能搞懂逻辑、确认是否真的修到了root cause且没有引入别的问题。 因此，当你通过长时间的合作证明了自己的能力和工作态度之后，对你的警惕自然可以降低，这样既可以节约你的精力，也可以节省评审者的时间。
归根结底，开发是一项合作性工作，并不是对抗性的——后者实在太累了——合作模型比起对抗性模型，工作量减少百倍不止。 不管你是什么开发团队、什么工作模型，默认“求职者是来合作而不是来对抗的”是一切的基础；只有在这个基础上，各种防呆甚至防傻的设计才能派上用场——注意难度次序：防呆难防傻，防傻不防坏。 很多时候，我们只能防君子不防小人，只能靠事后的惩罚让小人不敢侵害。原因就是傻比呆更难防；而一个憋着坏的人，任何人都无能为力。
这是因为，哪怕对一个中等规模、更新不太频繁的软件，逐一审核也实在太难了。 而且，要审核到什么程度才够呢？ 错误代码？ 无意引入的bug？ 有意植入的bug？ 有意植入同时又尽量隐蔽起来的后门？ 多个不同来源的patch组合起来才能激活的超隐蔽后门？ 过去，这些靠自觉，靠后期的大量测试，也靠主动拉黑那些不诚信的提交。但这事开了一个极坏的头，借研究的名义往代码库丢垃圾，DDoS攻击审核者... 一旦开了先例，每个patch付出一百倍精力够不够？一千倍精力能确保发现精心隐藏的后门吗？ 这还有办法做事吗？ 因此，软件开发很多时候也需要靠“混个脸熟”。 有了足够的信任度，你提交代码就更容易被接受，双方都轻松。
换句话说：如果你真的一定要往Linux内核植入后门，那么你一定能做到。并没有可靠的办法预先识别出程序中隐蔽的错误。 但做到的前提是，你最好先持续贡献十年乃至二十年的优质代码、在社区取得较高威望；然后放弃这一切，搞个破坏。
再换句话说：软件开发领域，合作者之间的信任、交情作用极大，是一种类似于“熟人社会”的关系。 这种社会里，信任关系想要可靠，那么对“背叛者”的惩罚就必须重。 不重，每个人都会想借他人的信任牟利。
比如说，明尼苏达大学，它的代码为何容易被社区接受？ 很简单，之前很多人的大量贡献为它赢得了信任。 基于这种信任，它的代码可能只需通过lint类工具检查、然后再被reviewer人工检查一遍就可以放心合入了——之后就是漫长的测试。
但现在，这些人滥用这种信任，故意提交包含bug的代码。这就把信任关系变成了对抗关系。 那么，如何处置呢？
如果轻轻放下，那么，下一次，另一所大学一个教授也往里面添加后门；然后被某个互联网大盗借此成功攻击了银行，怎么办？ 人家辩解说自己是无意的，你拿不出证据，怎么办？ 人家辩解说自己也不过是做测试而已，谁知道怎么那么巧就被利用了，怎么办？
很显然，这事绝不能善了。 你来对抗，那好，你就是敌人。 这是你自己选择的位置。 你凭什么获得我的信任？凭的是明尼苏达大学的邮箱。 那好，既然你这所大学站到了对抗立场，那么我当然就应该废弃你这整所大学提交的一切代码——直到你的大学赶你滚蛋、向我证明你们的非对抗性。 靠信任维持的系统里，只有对背叛者的惩罚足够严厉，才能确保不会有其它人借助信任提交对抗性代码。 这个逻辑的根本原因有如下几点： 1、的确没有办法100%的提前发现代码中暗藏的后门 2、的确有一些高手可以通过review找出代码中绝大多数的漏洞，但这种高手时薪一定高的吓人 3、如果任意三行代码都必须最高等级的reviewer前看五百行后看八百行……那还开个鬼源。让这位reviewer自己写不就完了。 4、考虑成本，社区自然只能借助信用等级来节约工作量 5、无法预检，可以借助信用等级免予严格审查；那么事后惩罚就必须迅速灵敏、且代价足够让任何人承受不起
这和惩治犯罪一样：既然我们没办法制定规则禁止杀人犯出生，那么就只能在他犯罪后严厉惩罚他。 这类东西如何研究？ 简单，分别找月薪4000、8000、12000、16000、20000、40000美元的开发者，分别给他们一组代码，告诉他们代码的作用以及代码中可能有bug，然后统计不同级别的开发者人工发现了多少百分比的故障代码，完事。 当然，如果这样做——这也是他们这个研究的本质——那么最傻的人都能看出这个研究很没意义。 除了再一次证明人类hold不住极端复杂的问题（或者研究者自己水平很渣设计不出真正“微妙”的bug），没有任何意义。
这就是问题的本质：一群水论文的垃圾研究者滥用社区的信任，给社区、给所在学校造成了重大损失，如此而已。
综上，求锤得锤，抱怨个鸡鸡。 编辑于 1 小时前
这件事情好几个层面。纯理工人士跟ethics watchdog看的角度不同. 首先网上为这位教授辩护的真不多，有的几个感觉自己也在写代码，而且是从实用出发，比如linux kernel 的维护确实有缺陷。 反对的大多数，理工人士说教授在浪费别人的时间，因为他说的安全隐患其实是常识，大家都早就知道。专注这个研究是否道德的反应就更激烈了
比如研究是先斩后奏，没有事先经过IRB的审核
Sarah Jamie Lewis @SarahJamieLewis
I see that we are talking about "Hypocrite Commits" again and I want to clarify a few things.
Despite what their paper says they didn't get an IRB-exemption until *after* they posted about their IEEESP paper acceptance and a group of researchers (inc myself) expressed concern...
认为IRB没有很好履行义务
Sarah Jamie Lewis @SarahJamieLewis · Apr 21
They lied to people in order to assess their response, with no system in place for prior informed consent or debriefing.
That any IRB could conclude that it wasn't a deception study on human subjects speaks to the overall ability of many IRBs to reason about internet studies.
高亮作者两篇文章中改动之处 （作者淡化后果）
I also want to take a moment to point out the original wording of their abstract (in their screenshot IEEESP announcement) v.s. the paper published in that repository.
"successfully introduced multiple exploitable...vulnerabilities"
v.s.
"safely demonstrate it is practical"
不认为文章有实用价值 （作者给linux oss其中一个建议，就是未来contributor要多加一句：我不会故意在代码中写bug)
> "but they still did demonstrate a flaw"
It was a known flaw, one practically every maintainer is aware of. The solution is safer languages with stronger security semantics coupled with automated testing and analysis tools. Initiatives that many people are actively working on.
最后，这位女士的总结 Anyway this is the latest in a long line of computer science researchers stumbling into human subject research, disregarding any and all ethical considerations, getting a paper published, and leaving to find a new community fuck around in.
因此，当你加入一家较为正规的公司、第一次修改bug时，那些老同事们往往就如临大敌，不得不一次次问你：你真的找到这个错误的root cause了吗？请证明你找到的是root cause……请证明除了root cause，其它错误不可能引起同样的故障…… 总之，经过很多轮的“审问”，你的patch才会被评审者接受，才可以合入软件仓库、进入测试流程……
随着你合入代码次数越来越多、且一直没有引起bug（或者很少引起bug），对你的“审问”就会越来越轻松——这是因为代码评审也是非常非常消耗精力的事情：为了合入三行代码，评审者很可能不得不参考前后超过五百行代码，这才能搞懂逻辑、确认是否真的修到了root cause且没有引入别的问题。 因此，当你通过长时间的合作证明了自己的能力和工作态度之后，对你的警惕自然可以降低，这样既可以节约你的精力，也可以节省评审者的时间。
因此，软件开发很多时候也需要靠“混个脸熟”。 有了足够的信任度，你提交代码就更容易被接受，双方都轻松。
换句话说：如果你真的一定要往Linux内核植入后门，那么你一定能做到。并没有可靠的办法预先识别出程序中隐蔽的错误。 但做到的前提是，你最好先持续贡献十年乃至二十年的优质代码、在社区取得较高威望；然后放弃这一切，搞个破坏。
再换句话说：软件开发领域，合作者之间的信任、交情作用极大，是一种类似于“熟人社会”的关系。 这种社会里，信任关系想要可靠，那么对“背叛者”的惩罚就必须重。 不重，每个人都会想借他人的信任牟利。
比如说，明尼苏达大学，它的代码为何容易被社区接受？ 很简单，之前很多人的大量贡献为它赢得了信任。 基于这种信任，它的代码可能只需通过lint类工具检查、然后再被reviewer人工检查一遍就可以放心合入了——之后就是漫长的测试。
但现在，这些人滥用这种信任，故意提交包含bug的代码。这就把信任关系变成了对抗关系。
对，你引用的这个部分，就是目前linux内核维护团队的日常操作流程，而他们ban 明尼大学的手法，感觉就是他们对待恶意代码的nuclear option ...
前面太啰嗦没看，我同意最后一句话。
所以現在為什麼要跟 刁 脫鉤
跟 刁 混在一起
成本會墊高很多
他没有砸碎那个门，只是贴个 flyer，告诉大家有这种可能性而已
貼個 flyer 詳述所將採用的 器材 工具 時間
而且匿名
那是得報警了
哈哈哈 我觉得是，他没砸碎，而是整块卸下来，然后又原封不动安回去。然后告诉大家他可以这么干。然后再写篇论文，论一个伪君子到社区后门卸下玻璃门的可能性。
我觉得在这个议题上面，一般理工科跟其他专业有代沟。因为只要是对human research有点常识的人，基本上都说这个研究有问题，IRB审核有缺陷，其严重性从这个Sarah James Lewis激烈的语气可见一斑。
中文把human research翻译成人体实验，好像要喂药才算人体实验，并不是这样。我以前参加过一个心理学phd的研究，其实只问了一些关于我们专业和工作环境的问题。但事先她要求我签同意书，解释研究的目的和内容，而且结束后我们每个参与人员还拿了点酬劳。
Umn 一个senior prof 正在twitter 上对话
他也要有能砸碎这个门的能耐，明明是个又坏又蠢的人，砸不碎被逮住，别给自己脸上贴金了
对的，这对于reviewer而言就是标准的DDoS。
话说他们那些垃圾代码review request乍一看还挺像模像样的，譬如这个——
On Mon, Aug 10, 2020 at 07:16:48AM +0200, Jiri Slaby wrote: > On 10. 08. 20, 0:14, James Bond wrote: > > Syzkaller find a memory leak in con_insert_unipair: > > BUG: memory leak > > unreferenced object 0xffff88804893d100 (size 256): > > comm "syz-executor.3", pid 16154, jiffies 4295043307 (age 2392.340s) > > hex dump (first 32 bytes): > > 80 af 88 4e 80 88 ff ff 00 a8 88 4e 80 88 ff ff ...N.......N.... > > 80 ad 88 4e 80 88 ff ff 00 aa 88 4e 80 88 ff ff ...N.......N.... > > backtrace: > > [<00000000f76ff1de>] kmalloc include/linux/slab.h:555 [inline] > > [<00000000f76ff1de>] kmalloc_array include/linux/slab.h:596 [inline] > > [<00000000f76ff1de>] con_insert_unipair+0x9e/0x1a0 drivers/tty/vt/consolemap.c:482 > > [<000000002f1ad7da>] con_set_unimap+0x244/0x2a0 drivers/tty/vt/consolemap.c:595 > > [<0000000046ccb106>] do_unimap_ioctl drivers/tty/vt/vt_ioctl.c:297 [inline] > > [<0000000046ccb106>] vt_ioctl+0x863/0x12f0 drivers/tty/vt/vt_ioctl.c:1018 > > [<00000000db1577ff>] tty_ioctl+0x4cd/0xa30 drivers/tty/tty_io.c:2656 > > [<00000000e5cdf5ed>] vfs_ioctl fs/ioctl.c:48 [inline] > > [<00000000e5cdf5ed>] ksys_ioctl+0xa6/0xd0 fs/ioctl.c:753 > > [<00000000fb4aa12c>] __do_sys_ioctl fs/ioctl.c:762 [inline] > > [<00000000fb4aa12c>] __se_sys_ioctl fs/ioctl.c:760 [inline] > > [<00000000fb4aa12c>] __x64_sys_ioctl+0x1a/0x20 fs/ioctl.c:760 > > [<00000000f561f260>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:384 > > [<0000000056206928>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: leak checking failed > > > > To fix this issue, we need to release the pointer p1 when the call of > > the function kmalloc_array fail. > > This reminds me of: > commit 15b3cd8ef46ad1b100e0d3c7e38774f330726820 > Author: Ben Hutchings <[email protected]> > Date: Tue Jun 4 19:00:39 2019 +0100 > > Revert "consolemap: Fix a memory leaking bug in > drivers/tty/vt/consolemap.c" > > This reverts commit 84ecc2f6eb1cb12e6d44818f94fa49b50f06e6ac. > > > > So NACK. I have a whole talk just about the "fun" involved with that change: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ > Do we have some annotations for this instead? We need something there, a comment saying "this is fine, don't touch it!" or something like that? We need that in a few other places in the vt code as well. > > Signed-off-by: James Bond <[email protected]> Nice name... James, can you mark this syzbot report as "invalid" or something like that please so that this does not come up again and again. thanks, greg k-h
这个SA工具是真的有，至于它是不是真的报告了这个问题就不知道了。然后reviewer们还在很认真地讨论，你这么修反倒会造成问题，之前就有类似的commit被revert，咱们是不是该在这里加个注释，不要动这一段代码……
linux内核的源代码可读性看来的确不行，所以review起来可想而知耗时耗力。不过这算是open source代码的通病了，freebsd也没好哪去，我的前公司就是在freebsd的基础上开发产品的，涉及freebsd内核的代码每每看得我想死。
无知和愚蠢是共生的。坐井观天的人，我是不会浪费时间给你普及社会常识和法律。你就继续想当然吧。
也不会所有的submit都去review和merge的，只有有信誉的submit才被考虑，别的一概不踩。
什么信誉？明大邮箱地址信誉？伪装个大学邮箱多简单的事儿。
那id是轮子，你跟他耗时间，他得开心死。他才不管什么社会常识，只要可以骂到华人或者任何和中国有关的估计都可以赚个5毛。。benefit drive的东西。
悲催的是，现实并非如此。那个垃圾代码带着的作者名是James Bond，一看就是马甲名字，他们还是很认真地回复和解释。
信誉也是要一点点build的，对于新人他们是友好的，但是往后会不会被这种操蛋研究逼得越来越不友好呢？
哈哈，学了，不是一直在偷吗？
……你开玩笑嘛？服务器大多都用linux啊
被linux kernel maintainers 黑名单很严重吗？明大这么多年也就是submit 几百个patches。 去年11月份已经有一波人跟明大抱怨这项研究了，结果IRB在研究结束后才review, review还得出不是human research的结论。没想到明大现在有些紧张了
这么说来把明大ban了真不冤啊。别人提出对这项研究的疑虑时他们装聋，非要等到事情闹这么大条才反应。
这事儿应该会影响到学校的名声吧。
你真不懂还是假不懂啊？ code review从来就没有过家家，还GOOD FAITH
我的论点是code review以后会变得很大量。big load。本来就不轻松的活，加上大量，会给整个社区带来变化。
你的论点是code review这活不轻松。跟我说的有什么关系吗？
我是在跟牛弹琴。
你完全不懂整件事带来的后果。 我都懒得和你争论这个。
挺严重的，相当于被江湖盟主立了个反面典型。整个Linux community这两天都知道了，绝大多数人都是愤怒的。
又是个洗地的。可以做检测工具（detect投毒的工具），为神马非要以身试法去投毒
这种坏人天天存在。明大之前几十年之后几十年都有。不会因为明大改变坏人。你还是先看看paper再发言吧。这又不是新鲜事。
在这领域挺新鲜的了，反正我和我同事们这么多年都是第一次听说这种奇葩事。paper我们都看过了，无法改变他奇葩无底线的结论。
所以你也是同意明大教授是坏人啰。那就结了，大家达成共识了😂
你这语文理解能力令人捉急。我说的是坏人投毒OOS不是新鲜事。他以身试法确实挺奇葩。
其实我一直在想这些open source的code是谁来review的，写的人可以是in good faith，但不代表code没有bug啊，就算是微软苹果也一直patch patch的来fix bugs。。。只要是人写的东西就有可能有bug。。。所以到底这个review process可靠不可靠啊？当然我不是支持故意提交有bug的程序给别人怎么工作量。。。