https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
posted some clarifications around this, worth a read
“They introduce kernel bugs on purpose”
581–590 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#582This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.
LKML should consider not just banning the @umn.edu on the SMTP but sinkholing the whole of University of MN network address space. Demand a public apology and paying for compute for the next 3 years or get yeeted
Re: “They introduce kernel bugs on purpose”
#583It's already being discussed on HN [1] but for some reason it's down to the 3rd page despite having ~1200 upvotes at the moment and ~600 comments, including from Greg KH. (And the submission is only 5 hours old.)
Re: “They introduce kernel bugs on purpose”
#584How is this any different to littering in order to research if it gets cleaned up properly? Or like dumping hard objects onto a highway to research if they cause harm before authorities notice it?
I mean, the Kernel is now starting to run in cars and even on Mars, and getting those bugs into stable is definitely no achievement one should be proud of.
Re: “They introduce kernel bugs on purpose”
#585Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug 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 proper patch. In all t…
> I haven't been able to find out what the 3 patches which the reference are, but the discussions on Greg's UMN Revert patch [2] does indicate that some of the fixes have indeed been merged to Stable and are actually Bogus.
That's because those are two separate incidents. The study which resulted in 3 patches was completed some time last year, but this new round of patches is something else.
It's not clear whether the patches are coming from the same professor/group, but it seems like the author of these bogus patches is a Phd student working with the professor who conducted that study last year. So there is at least one connection.
EDIT: also, those 3 patches were supposedly submitted using a fake email address according to the "clarification" document released after the paper was published. So they probably didn't use a @umn.edu email at all.
Re: “They introduce kernel bugs on purpose”
#586Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug 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 proper patch. In all t…
The response makes the researchers seem clueless, arrogant, or both - are they really surprised that kernel maintainers would get pissed off at someone deliberately wasting their time?
From the post:
* Does this project waste certain efforts of maintainers?
Unfortunately, yes. We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their precious time. We had carefully considered this issue, but could not figure out a better solution in this study. However, to minimize the wasted time, (1) we made the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we tried hard to find three real bugs, and the patches ultimately contributed to fixing them
Re: “They introduce kernel bugs on purpose”
#587The tone of Aditya Pakki's message makes me think they would be very well served by reading 'How to Win Friends & Influence People' by Dale Carnegie. This is obviously the complete opposite of how you should be communicating with someone in most situations let alone when you want something from them. I have sure been there though so if anything, take this as a book recommendation for 'How to Win Friends & Influence P…
I’ve seen this book mentioned a couple of times on HN now. I’m curious: did you learn about this book from the fourth season of the Fargo? This is where I encountered it first.
It's a common recommendation for many decades now, you aren't going to find any one particular vector.
Re: “They introduce kernel bugs on purpose”
#588Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug 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 proper patch. In all t…
In the end, the damage has been done and the Linux developers are now going back and removing all patches from any user with a @umn.edu email. Not sure how the researchers didn't see how this would backfire, but it's a hopeless misuse of their time. I feel really bad for the developers who now have to spend their time fixing shit that shouldn't even be there, just because someone wanted to write a paper and their pee…
This, in of itself, is a finding. The researchers will justify their research with "we were banned which is a possible outcome of this kind of research..." I find this disingenuous. When a community of open source contributors is partially built on trust, then violators can and will be banned.
The researchers should have approached the maintainers got get buy in, and setup a methodology where a maintainer would not interfere until a code merge was immanent, and just play referee in the mean time.
Re: “They introduce kernel bugs on purpose”
#589Unsurprising given the current open sores model of software
Re: “They introduce kernel bugs on purpose”
#590The replies here have been fascinating to read. Yes it's bad that subterfuge was engaged in vs kernel devs. But don't the many comments here expressing outrage at the actions of these researchers sound exactly like the kind of outrage commonly expressed by those in power when their misdeeds are exposed? e.g. Republican politicians outraged at a "leaker" who has leaked details of their illegal activity. It honestly lo…
One very good security practice is that if you find that you have a malicious contributor, you fire that contributor. The "misdeeds" were committed by the UMN researchers, not by the Linux maintainers.