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

921–930 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#921

Post by mnouquet »

burnished wrote: post #834
mnouquet wrote: post #677

In other news: the three little pigs ban wolves after wolves exposed the dubious engineering of the straw house by blowing on it for a research paper.

So if an identifiable group messes with a project, but says "its for research!", then its OK? I'm just confused by your comment because it seems like you are upset with the maintainers for protecting their time from sources of known bad patches. And just... why? Where does the entitlement come from?

Being a maintainer is being a gate-keeper, by definition. Don't get me started about their "time", most of these guys are paid to work on the linux kernel, eg. Greg Kroah-Hartman is paid by the Linux Foundation. it's literally his job. Linus has balls, I'm afraid Greg KH is a Karen compared to him.

Other than that, they got caught red-handed accepting shit patch and complain about ethical issues when the fault is entirely on their side for not doing their job properly.

This whole thing points to a single question: how many times did they accept patch from black hat individuals who did not disclose their intention ?

This question the Linux development security model and highlight it being insecure to such social engineering attacks and they still manage to play victims. That's pitiful... Own it, say you fucked up accepting the patch, don't blame other for your own incompetence.

Re: “They introduce kernel bugs on purpose”

#922

Post by neatze »

altouring wrote: post #878
killjoywashere wrote: post #848

Earlier quoted context omitted.

Not that I approve of the methods, but why would an IRB be involved in a computer security study? IRBs are for human subjects research. If we have to run everything that looks like any kind of research through IRBs, the Western gambit on technical advantage is going to run into some very hard times.

The subjects were the kernel team. They should have had consent to be part of this study. It's like red team testing, someone somewhere has to know about it and consent to it.

How IEEE accepted this paper is a mystery, from twitter feeds, seems like at least one complaint was filled with IEEE, paper still was accepted.

Re: “They introduce kernel bugs on purpose”

#924

Post by mariojv »

Aissen wrote: post #253

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

Seriously.... I am undecided one way or another on reverting everything, but I am happy that someone is looking closely at this.

One thing I hope they have considered is a possible intent to get a particular important patch from umn.edu reverted to reintroduce a kernel bug. Discrediting all commits from the organization could inadvertently lead to the reintroduction of legacy exploits.

Re: “They introduce kernel bugs on purpose”

#925

Post by cookiengineer »

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

Thanks for your important work, Greg!

I'm currently wondering how much of these patches could've been flagged in an automated manner, in the sense of fuzzing specific parts that have been modified (and a fuzzer that is memory/binary aware).

Would a project like this be unfeasible due to the sheer amount of commits/day?

Re: “They introduce kernel bugs on purpose”

#926

Post by nousermane »

sesuximo wrote: post #264
Aissen wrote: post #253

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

How does the kernel still run after reverting like this?

In all likelihood, it'll run just fine.

Skimming through subject lines of 190 commits being reverted here, every single one of them is along the lines of "add refcount/NULL/etc check and conditionally do (or do not) de-allocate memory before error-path return". I.e. worst case - this will reintroduce some rare memory leak or memory lifecycle bug.

Also, all of patches in question are in drivers. So depending on hardware used, any given system's user is likely to only have to worry about 2-3, maybe 5 of the patches, not all 190.

Re: “They introduce kernel bugs on purpose”

#927

Post by smsm42 »

lbarrow wrote: post #586
karsinkk wrote: post #521

Here'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 prec…

Your honor, I tried to find any solution for testing this new poison without poisoning a bunch of people, but I carefully considered it and I couldn't find any, so I went ahead and secretly poisoned them. Clearly, I am innocent! Though I sincerely apologize for any inconvenience caused.

Re: “They introduce kernel bugs on purpose”

#928

Post by bawolff »

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…

Why? Linux is not the state. There is no entitlement to rights or presumption of innocence.

Linux is set up to benefit the linux development community. If UMinn has basically no positive contributions, a bunch of neutral ones and some negative ones banning seems the right call.

Its not about fairness, its about if the hurts outweigh the benefits.

Re: “They introduce kernel bugs on purpose”

#929

Post by NavinF »

Frost1x wrote: post #353
macspoofing wrote: post #290

Linux maintainers should log a complaint with the University's ethics board. You can't just experiment on people without consent.

I always find the dichotomy we have regarding human subject experimentation interesting in the US. We essentially have two ecosystems of human subjects as to what is allowed and isn't: public and privately funded. The contrast is a bit stark. We have public funded rules (typically derived or pressured by availability of federal or state monies/resources) which are quite strict, have ethics and IRB boards, cover even…

https://xkcd.com/1390
Post reply on HN