4 ms·

Intentionally buggy commits for fame and papers (2021)

42 points by mmsc 3y ago

samcullin 3y ago
[flagged]
kseifried 3y ago
We covered this back then on the #osspodcast: Episode 269 – Do not experiment on the Linux Kernel https://opensourcesecurity.io/2021/05/02/episode-269-do-not-experiment-on-the-linux-kernel/ https://opensourcesecurity.io/2021/05/02/episode-269-do-not-... Josh and Kurt talk about the University of Minnesota experimenting on the Linux Kernel. There’s a lot to unpack in this one, but the TL;DR is you probably don’t want to experiment on the kernel.
- atq2119 3y ago
  Yeah, my first reaction to this was "WTF, again?!". Then I noticed the date. Needs a (2021)
- dwheeler 3y ago
  I'd tweak that statement. Experimenting on the kernel is fine. Experimenting on humans without their consent is not fine.
Karellen 3y ago
(2021)
- dang 3y ago
  Added above. Thanks!
ksherlock 3y ago
Umm, 2021.
KolmogorovComp 3y ago
Since it’s from 2021, does anybody has a follow-up on this? What happened to the researchers? Did something changed in the patch process to limit these attempts?
- dharmab 3y ago
  Linux Foundation TAB report: https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ - bottom of the report made a recommendation each for UMN and the TAB UMN statement: https://cse.umn.edu/cs/statement-computer-science-engineering-confirming-linux-technical-advisory-board-findings-may-9 https://cse.umn.edu/cs/statement-computer-science-engineerin...
- dwheeler 3y ago
  Here's the letter from the Linux Foundation: https://www.zdnet.com/article/the-linux-foundations-demands-to-the-university-of-minnesota-for-its-bad-linux-patches/ https://www.zdnet.com/article/the-linux-foundations-demands-... Full disclosure: it is from Mike Dolan, but I wrote a substantial part of it. Yes, things did change. 1. UMN got pull on a "ban" list which means someone else has to review their proposals before they will be considered by the kernel community. The purpose is not to punish, but rehabilitate. So hopefully they'll get off the list (they may have already done so, I haven't checked recently). 2. The Linux Foundation and UMN had a formal meeting. The goal wasn't to hurt UMN, just to prevent recurrence. UMN agreed to ensure all CS faculty got training on Institutional Review Boards (IRBs), including the rules on experiments involving humans. 3. The Linux kernel now has a much clearer statement about research, here: https://www.kernel.org/doc/html/latest/process/researcher-guidelines.html https://www.kernel.org/doc/html/latest/process/researcher-gu... Again, the goal was focused on resolving any issues and preventing recurrence. I don't know of any recurrence, so I think we can count these changes as a success.
throwup238 3y ago
Previous discussion when this story originally broke: “They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670 - April 2021 (1954 comments)
dataangel 3y ago
I find this research to be both ethical and necessary, and I think kernel devs decrying it as wasting their time are missing the point. They demonstrated the whole "with enough eyes all bugs are shallow" security model doesn't really work. If some of the best devs out there fall for bad patches, it can happen to any OSS project (and for that matter for prop code bases too, but there you at least have to go through the hurdle of being hired before your code is considered).
- robertlagrant 3y ago
  Why's it necessary? We already know that this method of software development, like all methods, isn't perfect if you pick a short enough timeframe.
- db48x 3y ago
  Did you read the report? (<https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/>) Allow me to quote from it: Patch 3 First email: Thu, 20 Aug 2020 22:44:57 -0500 (Fri, 21 Aug 2020 03:44:57 UTC) First reply: Fri, 21 Aug 2020 11:14:49 +0300 (Fri, 21 Aug 2020 08:14:49 UTC) https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com This patch was quickly recognized by a reviewer to be incorrect, and the reviewer offered up possible changes that the submitter could make in order to turn it into a correct change. These suggestions were ignored by the submitter and no further changes were submitted in this area. The maintainer was attempting to mentor an obviously junior contributor, taking time to teach the developer what the proper thing to do here would be, and what is needed in order to have them create a contribution that would be acceptable. The contributor knew that the patch was bad, showing that the researchers were willing to waste the resource that is in shortest supply in our community: the time of reviewers and maintainers. Having this waste of an "effort of someone trying to teach another" be created by an educational institution was especially hurtful to the community and caused many of the bad feelings on the community's side, further amplified by not having any idea which patches out of the hundreds sent by UMN or from new contributors using gmail accounts might be intentionally bad. […] Summary of "Hypocrite Commits" patch attempts All patch submissions that were invalid were caught, or ignored, by the Linux kernel developers and maintainers. Our patch-review processes worked as intended when confronted with these malicious patches. As you can see, the time that was wasted was especially valuable, and the research did not demonstrate any such thing.
alumnumn 3y ago
As an alumn it’s pretty annoying to see UMN dragged through the mud by assholes trying to get papers, even a few years on.
up2isomorphism 3y ago
It is obviously a valid research, as it proves a possible security flaws in the process. But on the other hand it is also obvious that kernel folks won’t entertain it unless it is just a technical matter. But we all know kernel community has been a very political space for a long time. Even Linus himself can not be excluded from it.

42 points by mmsc 3y ago

[flagged]

We covered this back then on the #osspodcast: Episode 269 – Do not experiment on the Linux Kernel https://opensourcesecurity.io/2021/05/02/episode-269-do-not-experiment-on-the-linux-kernel/ https://opensourcesecurity.io/2021/05/02/episode-269-do-not-... Josh and Kurt talk about the University of Minnesota experimenting on the Linux Kernel. There’s a lot to unpack in this one, but the TL;DR is you probably don’t want to experiment on the kernel.

atq2119 3y ago
Yeah, my first reaction to this was "WTF, again?!". Then I noticed the date. Needs a (2021)
dwheeler 3y ago
I'd tweak that statement. Experimenting on the kernel is fine. Experimenting on humans without their consent is not fine.

Karellen 3y ago

(2021)

dang 3y ago
Added above. Thanks!

ksherlock 3y ago

Umm, 2021.

KolmogorovComp 3y ago

Since it’s from 2021, does anybody has a follow-up on this? What happened to the researchers? Did something changed in the patch process to limit these attempts?

dharmab 3y ago
Linux Foundation TAB report: https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ - bottom of the report made a recommendation each for UMN and the TAB UMN statement: https://cse.umn.edu/cs/statement-computer-science-engineering-confirming-linux-technical-advisory-board-findings-may-9 https://cse.umn.edu/cs/statement-computer-science-engineerin...
dwheeler 3y ago
Here's the letter from the Linux Foundation: https://www.zdnet.com/article/the-linux-foundations-demands-to-the-university-of-minnesota-for-its-bad-linux-patches/ https://www.zdnet.com/article/the-linux-foundations-demands-... Full disclosure: it is from Mike Dolan, but I wrote a substantial part of it. Yes, things did change. 1. UMN got pull on a "ban" list which means someone else has to review their proposals before they will be considered by the kernel community. The purpose is not to punish, but rehabilitate. So hopefully they'll get off the list (they may have already done so, I haven't checked recently). 2. The Linux Foundation and UMN had a formal meeting. The goal wasn't to hurt UMN, just to prevent recurrence. UMN agreed to ensure all CS faculty got training on Institutional Review Boards (IRBs), including the rules on experiments involving humans. 3. The Linux kernel now has a much clearer statement about research, here: https://www.kernel.org/doc/html/latest/process/researcher-guidelines.html https://www.kernel.org/doc/html/latest/process/researcher-gu... Again, the goal was focused on resolving any issues and preventing recurrence. I don't know of any recurrence, so I think we can count these changes as a success.

throwup238 3y ago

Previous discussion when this story originally broke: “They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670 - April 2021 (1954 comments)

dataangel 3y ago

I find this research to be both ethical and necessary, and I think kernel devs decrying it as wasting their time are missing the point. They demonstrated the whole "with enough eyes all bugs are shallow" security model doesn't really work. If some of the best devs out there fall for bad patches, it can happen to any OSS project (and for that matter for prop code bases too, but there you at least have to go through the hurdle of being hired before your code is considered).

robertlagrant 3y ago
Why's it necessary? We already know that this method of software development, like all methods, isn't perfect if you pick a short enough timeframe.
db48x 3y ago
Did you read the report? (<https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/>) Allow me to quote from it: Patch 3 First email: Thu, 20 Aug 2020 22:44:57 -0500 (Fri, 21 Aug 2020 03:44:57 UTC) First reply: Fri, 21 Aug 2020 11:14:49 +0300 (Fri, 21 Aug 2020 08:14:49 UTC) https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com This patch was quickly recognized by a reviewer to be incorrect, and the reviewer offered up possible changes that the submitter could make in order to turn it into a correct change. These suggestions were ignored by the submitter and no further changes were submitted in this area. The maintainer was attempting to mentor an obviously junior contributor, taking time to teach the developer what the proper thing to do here would be, and what is needed in order to have them create a contribution that would be acceptable. The contributor knew that the patch was bad, showing that the researchers were willing to waste the resource that is in shortest supply in our community: the time of reviewers and maintainers. Having this waste of an "effort of someone trying to teach another" be created by an educational institution was especially hurtful to the community and caused many of the bad feelings on the community's side, further amplified by not having any idea which patches out of the hundreds sent by UMN or from new contributors using gmail accounts might be intentionally bad. […] Summary of "Hypocrite Commits" patch attempts All patch submissions that were invalid were caught, or ignored, by the Linux kernel developers and maintainers. Our patch-review processes worked as intended when confronted with these malicious patches. As you can see, the time that was wasted was especially valuable, and the research did not demonstrate any such thing.

alumnumn 3y ago

As an alumn it’s pretty annoying to see UMN dragged through the mud by assholes trying to get papers, even a few years on.

up2isomorphism 3y ago

It is obviously a valid research, as it proves a possible security flaws in the process. But on the other hand it is also obvious that kernel folks won’t entertain it unless it is just a technical matter. But we all know kernel community has been a very political space for a long time. Even Linus himself can not be excluded from it.