“They introduce kernel bugs on purpose” • Hacker News Board

Re: “They introduce kernel bugs on purpose”

#971

Post by nialv7 » Thu, Apr 22, 2021, 2:28 PM UTC

gregkh wrote: post #267

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

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...

I have to ask: were they not properly reviewed when they were first merged?

Also to assume _all_ commits made by UMN, beyond what's been disclosed in the paper, are malicious feels a bit like an overreaction.

Re: “They introduce kernel bugs on purpose”

#972

Post by ginko » Thu, Apr 22, 2021, 2:58 PM UTC

throwawayffffas wrote: post #47

As a user of the linux kernel, I feel legal action against the "researchers" should be pursued.

I believe as a user of the kernel the warranty exclusion in GPLv2 means you have no legal recourse:

> 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

..which is generally a good thing even if it also protects clearly malicious actions like this.

Re: “They introduce kernel bugs on purpose”

#973

Post by iSnow » Thu, Apr 22, 2021, 3:09 PM UTC

alxlaz wrote: post #259

bluGill wrote: post #213

Earlier quoted context omitted.

If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…

This is, at the very least, worth an investigation from an ethics committee. First of all, this is completely irresponsible, what if the patches would've made their way into a real-life device? The paper does mention a process through which they tried to ensure that doesn't happen, but it's pretty finicky. It's one missed email or one bad timezone mismatch away from releasing the kraken. Then playing the slander vict…

>It's one missed email or one bad timezone mismatch away from releasing the kraken.

I don't think code commits to the Linux kernel make it to live systems that fast?

I do agree with the sentiment, though. It's grossly irresponsible to do that without asking at least someone in the kernel developer's group. People don't dig being used as lab rats, and now the whole uni is blocked. Well, tough shit.

Re: “They introduce kernel bugs on purpose”

#974

Post by oauea » Thu, Apr 22, 2021, 3:21 PM UTC

gregkh wrote: post #267

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

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?

Re: “They introduce kernel bugs on purpose”

#975

Post by vintnes » Thu, Apr 22, 2021, 3:22 PM UTC

karlding wrote: post #818

The University of Minnesota's Department of Computer Science and Engineering released a statement [0] and "suspended this line of research". [0] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...

According to the "Hypocrite Commits" paper by Qiushi Wu, UMN specifically approved this research, granting IRB exemption.

https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...

See section VI-A (page 8).

Re: “They introduce kernel bugs on purpose”

#976

Post by detaro » Thu, Apr 22, 2021, 3:30 PM UTC

vintnes wrote: post #975

karlding wrote: post #818

The University of Minnesota's Department of Computer Science and Engineering released a statement [0] and "suspended this line of research". [0] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...

According to the "Hypocrite Commits" paper by Qiushi Wu, UMN specifically approved this research, granting IRB exemption. https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap... See section VI-A (page 8).

That doesn't conflict with the statement. If the IRB looks at something and exempts it, it has no reason to report that to the hierarchy in any way, because that's a routine process.

Re: “They introduce kernel bugs on purpose”

#977

Post by detaro » Thu, Apr 22, 2021, 3:31 PM UTC

de6u99er wrote: post #882

karlding wrote: post #818

The University of Minnesota's Department of Computer Science and Engineering released a statement [0] and "suspended this line of research". [0] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...

Not sure how this university is run but this doesn't sound plausible to me. >... learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel And this sounds like mainly a lot of damage control is going to happen. >We will report our findings back to the community as soon as practical.

Why does it sound implausible? In any uni I've interacted with, profs did pretty much their own thing and without a reason very little attention is paid to how they do it (or even what they do).

Re: “They introduce kernel bugs on purpose”

#978

Post by ajarmst » Thu, Apr 22, 2021, 4:15 PM UTC

neatze wrote: post #601

ajarmst wrote: post #566

I used to sit on a research ethics board. This absolutely would not have passed such a review. Not a 'revise and resubmit' but a hard pass accompanied with 'what the eff were you thinking?. And, yes, this should have had a REB review: testing the vulnerabilities of a system that includes people is experimenting on human subjects. Doing so without their knowledge absolutely requires a strict human subject review and t…

This is my understanding as well, but then, how such paper was accepted by IEEE ?

Not sure. I expect that editors at such journals tend to assume that studies with an institutional sponsor will be held to professional standards by the sponsor, or take the authors' assertions at face value. I suspect that reviewers might have assumed that the study was done with the knowledge and permission of GNU project managers, even if not the line programmers (as in the case of ethical pen testing). That would make it less of an obvious ethical breach.

Re: “They introduce kernel bugs on purpose”

#979

Post by rk06 » Thu, Apr 22, 2021, 4:38 PM UTC

duxup wrote: post #171

ENOTTY wrote: 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…

Seems like a bit of a strong response. Universities are large places with lots of professors and people with different ideas, opinions, views, and they don't work in concert, quite the opposite. They're not some corporation with some unified goal or incentives. I like that. That's what makes universities interesting to me. I don't like the standard here of of penalizing or lumping everyone there together, regardless…

that is completely irrelevant. they are acting under the university, and their "Research" is backed by university and approved by university's department.

if university has a problem, then they should first look into managing this issue at their end, or force people to use personal email ids for such purposes

Re: “They introduce kernel bugs on purpose”

#980

Post by rationalfaith » Thu, Apr 22, 2021, 5:05 PM UTC

The experiment is ridiculous and apathetic. You need consent to deal with this. They could've funded some internal project and have people at random submit commits and a control group that doesn't What they did is unethical to the max.

Good job on Greg for holding ground.