Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

Post reply on HN
Print view View original

801–810 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#801

Post by dm319 »

Fordec wrote: post #798

In Ireland there was a referendum to repeal the ban on abortion referendum there was very heated arguments, bot twitter accounts and general toxicity. For the sake of peoples sanity, there was a "Repeal Shield" implemented that blocked bad faith actors. This news makes me wish to implement my own block on the same contributors to any open source I'm involved with. At the end of the day, their ethics is their ethics.…

I think that is a sensible way to deal with this problem. The linux community is based on trust (as are a lot of other very successful communities), and ideally we trust until we have reason not to. But at that point we do need to record who we don't trust. It is the same in academia and sports.

Re: “They introduce kernel bugs on purpose”

#802

Post by gonehome »

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 hope they take this bad publicity and stop (rather than escalating stupidity by using non university emails).

What a joke - not sure how they can rationalize this as valuable behavior.

Re: “They introduce kernel bugs on purpose”

#803

Post by kahrl »

zulban wrote: post #367
duxup wrote: post #360

I don't like this university ban approach. Universities are places with lots of different students, professors, and different people with different ideas, and inevitably people who make bad choices. Universities don't often act with a single purpose or intent. That's what makes them interesting. Prone to failure and bad ideas, but also new ideas that you can't do at corporate HQ because you've got a CEO breathing dow…

It sends a strong message - universities need to make sure their researchers apply ethics standards to any research done on software communities. You can't ignore ethics guidelines like consent and harm just because it's a software community instead of a meatspace community. I doubt the university would have taken any action at all without such a response.

Has the university taken action yet? All I heard was after blowback, UMN had their institutional review board retroactively review the paper. They investigated themselves and found no wrongdoing. (IRB concluded this was not human research)

UMN hasn't admitted to any wrongdoing. The professor wasn't punished in any form whatsoever. And they adamantly state that their research review processes are solid and worked in this case.

An indefinite ban is 100% warranted until such a time that UMN can demonstrate that their university sponsored research is trustworthy and doesn't act in bad faith.

Re: “They introduce kernel bugs on purpose”

#805

Post by slohr »

tpoacher wrote: post #245
kop316 wrote: post #226

Earlier quoted context omitted.

Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094

This is now my second favourite paper after the atlantic salmon in fmri

My gateway pub to this type of research was the Stork paper: https://pubmed.ncbi.nlm.nih.gov/14738551/

Re: “They introduce kernel bugs on purpose”

#806

Post by alkonaut »

If you really wanted to research how to get malicious code into the highest-profile projects like Linux, the social engineering bit would be the most

Whether some unknown contributor can submit a bad patch isn't so interesting for this type of project. Knowing the payouts for exploits, the question is: how much money would one bad reviewer want to let one past?

Re: “They introduce kernel bugs on purpose”

#807

Post by nwelna »

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

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.

Re: “They introduce kernel bugs on purpose”

#808

Post by WmyEE0UsWAwC2i »

Cpoll wrote: post #469
gregkh wrote: post #267

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

A lot of people are talking about the ethical aspects, but could you talk about the security implications of this attack? From a different thread: https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... > A lot of these have already reached the stable trees. Apologies in advance if my questions are off the mark, but what does this mean in practice? 1. If UNM hadn't brought any attention to these, would they h…

I agree with the sentiment. For a project of this magnitude maybe it comes to develop some kind of static analysis along with refactoring the code to make the former possible.

As per the attack surface described in the paper (section IV). Because (III, the acceptance process) is a manpower issue.

Re: “They introduce kernel bugs on purpose”

#809

Post by aidenn0 »

walrus01 wrote: post #147
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…

> I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"

Put a flaming bag of shit on the doorstep, ring the doorbell, and write a paper about the methods Liu uses to extinguish it?

Re: “They introduce kernel bugs on purpose”

#810

Post by FrameworkFred »

tcelvis wrote: post #664
gregkh wrote: post #267

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

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person…

In a perfect world, I would agree that the work of a researcher who's not an established figure in the kernel community would be met with a relatively high level of scrutiny in review.

But realistically, when you find out a submitter had malicious intent, I think it's 100% correct to revisit any and all associated submissions since it's quite a different thing to inspect code for correctness, style, etc. as you would in a typical code review process versus trying to find some intentionally obfuscated security hole.

And, frankly, who has time to pick the good from the bad in a case like this? I don't think it's an overreaction at all. IMO, it's a simplification to assume that all associated contributions may be tainted.

Post reply on HN