Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

41–50 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#43
post #16

The problem here is really that they’re wasting time of the maintainers without their approval. Any ethics board would require prior consent to this. It wouldn’t even be hard to do.

1) They identified vulnerabilities with a process 2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 3) Getting the consent of the people behind the process would invalidate the results.

Go hack a random organization without a vulnerability disclosure program in place and see how much goodwill you have. There is a very established best practice in how to do responsible disclosure and this is far from it.

Re: “They introduce kernel bugs on purpose”

#44
post #22

Later 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…

Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.] They are conducting research to demonstrate that it is easy to introduce bugs in open source... (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) [removed this ranting that does not apply since they are contributing a lot to the kernel in g…

> It's likely a university with professors that hate open source.

This is a ridiculous conclusion. I do agree with the kernel maintainers here, but there is no way to conclude that the researchers in question "hate open source", and certainly not that such an attitude is shared by the university at large.

Re: “They introduce kernel bugs on purpose”

#45

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I'm on. While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best . Two messages down in the same thread, it m…

> While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best.

I agree. I would say this is kind of a "human process" analog of your typical computer security research, and that this behavior is akin to black hats exploiting a vulnerability. Totally not OK as research, and totally reckless!

Re: “They introduce kernel bugs on purpose”

#46

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I'm on. While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best . Two messages down in the same thread, it m…

Are there any measures being discussed that could make such attacks harder in future?

Re: “They introduce kernel bugs on purpose”

#48
post #16

The problem here is really that they’re wasting time of the maintainers without their approval. Any ethics board would require prior consent to this. It wouldn’t even be hard to do.

1) They identified vulnerabilities with a process 2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 3) Getting the consent of the people behind the process would invalidate the results.

> 3) Getting the consent of the people behind the process would invalidate the results.

This has not been a valid excuse since the 1950s. Scientists are not allowed to ignore basic ethics because they want to discover something. Deliberately introducing bugs into any open source project is plainly unethical; doing so in the Linux kernel is borderline malicious.

Re: “They introduce kernel bugs on purpose”

#49
post #2

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... That said the current incident seems to have gone beyond the limits of that one and is a new incid…

From their explanation: (3). We send the incorrect minor patches to the Linux community through email to seek their feedback. (4). 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 the three…

In the last year when it came to experimental Covid-19 projections, modeling and population-wide recommendations from major academic centers, the IRB's were silent and academics did essentially whatever they wanted, regardless of "consent" from the populations that were the subjects of their speculative hypotheses.

Re: “They introduce kernel bugs on purpose”

#50
post #2

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... That said the current incident seems to have gone beyond the limits of that one and is a new incid…

From their explanation: (3). We send the incorrect minor patches to the Linux community through email to seek their feedback. (4). 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 the three…

You could argue that they are doing the maintainers a favor. Bad actors could exploit this, and the researchers are showing that maintainers are not paying enough attention.

If I were at the receiving end, I’d think checking a patch multiple times before accepting it.

Post reply on HN