Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... [PATCH 000/190] Revertion of all of the umn.edu commits
Greg should invoice the university for the time spent fixing this mess
“They introduce kernel bugs on purpose”
981–990 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#982Earlier quoted context omitted.
Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...
As an Alumni of the University of Minnesota's program I am appalled this was even greenlit. It reflects poorly on all graduates of the program, even those uninvolved. I am planning to email the department head with my disapproval as an alumni, and I am deeply sorry for the harm this caused.
>It reflects poorly on all graduates of the program
how it does?
Re: “They introduce kernel bugs on purpose”
#983Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…
> Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. That's the university's problem to fix.
If this experience doesn't change not only the behavior of U of M's IRB but inform the behavior of every other IRB, then nothing at all is learned from this experience.
Unless both the professors and leadership from the IRB aren't having an uncomfortable lecture in the chancellor's office then nothing at all changes.
Re: “They introduce kernel bugs on purpose”
#984Earlier quoted context omitted.
Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...
> should be aware that future submissions from anyone with a umn.edu address should be by default-rejected Are you not concerned these malicious "researches" will simply start using throwaway gmail addresses?
Are throwaway gmail addresses nearly as 'trusted'?
Re: “They introduce kernel bugs on purpose”
#985From an outsider, the main question is: does this expose an actual weakness in the Linux development model? From what I understand, this answer seems to be a "yes". Of course, it is understandable that GKH is frustrated, and if his community do not like someone pointing out this issue, it is OK too. However, one researcher does not represent the whole university, so it seems immature to vent this to other unrelated p…
The main issue is that the researchers are now untrustworthy because they conducted this experiment without permission. Essentially, the kernel dev team can no longer trust that any given patch from U of M isn't the same research team using a different email address to submit more malicious patches.
You actually think there should be way to "trust" someone by looking at his/her Email address domain?
Re: “They introduce kernel bugs on purpose”
#986Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kerne…
Aditya's story about the new patches is that he was writing a static analysis tool and was testing it by... submitting PRs to the Linux kernel? He's either exploiting the Linux maintainers to test his new tool, or that story's bullshit. Even taking his story at face value is justification to at least ban him personally IMO.
Sounds like these commits aren't related to that paper, they're related to the next paper he's working on, and the next one is making the same category error about human subjects in his study.
Re: “They introduce kernel bugs on purpose”
#987It'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.) [1] https://news.ycombinator.com/item?id=26887670
Sorry, we got that wrong. Fixed now. Edit: turns out it was just that there were two different threads on the frontpage about this story and a moderator downweighted the earlier one. That's standard moderation. Usually we merge the threads (and I've since done so) but I'm the only mod who currently does that and I wasn't online yet.
Great, thanks for fixing it!
Re: “They introduce kernel bugs on purpose”
#988I did my Ph.D in cognitive neuroscience, where I conducted experiments on human subjects. Running these kinds of experiments required approval from an ethics committee, which for all their faults (and there are many), are quite good at catching this kind of shenanigans. Is there not some sort of equivalent in this field?
It seems they lied to the ethics committee. But I'm not holding my breath for the University to sanction them or withdraw/EoC their papers, because Universities prefer to have these things swept under the carpet.
There's no evidence of that. It appears to be purely a rumor being spread around there with no facts to back it up.
Re: “They introduce kernel bugs on purpose”
#989Earlier quoted context omitted.
Perhaps the Linux kernel team should actively support a Red Team to do this with a notification when it would be merged into the stable branch.
What would be the point? Of course people can miss things in code review. Yet the Linux developer base and user base has decided that generally an open submission policy has benefits that outweigh the risks. Should every city park with a "no alcohol" policy conduct red teams on whether it's possible to smuggle alcohol in? Should police departments conduct red teams to see if people can get away with speeding?
Let's say that no one has ever seen someone speeding or drinking the park. But then someone announces that they just did it, got away with it, and the system isn't effective at catching folks that violate the policies. It might make sense to figure out how you could change the way the system works to stop people from violating the policy. One way to do that is to replicate the violation and see what measures could be introduced to decrease the likely-hood. I would say it is very much akin to the companies that test to see if your employees can be phished or the pen testers to see if you can be hacked. Other important things that people want to protect have these teams to make them a harder target and I think in the case of something as important as the Linux Kernel it might pay dividends.
Re: “They introduce kernel bugs on purpose”
#990Sending those patches is just disgraceful. I guess they're using the edu emails so banning the university is a very effective action so someone will respond to it. Otherwise, the researchers will just quietly switch to other communities such as Apache or GNU. Who want buggy patches?
They used gmail.