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

551–560 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#551

Post by remram »

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!"

The actual equivalent would be to steal his computer, wait a couple days to see his reaction, get a paper published, then offer to return the computer.

Re: “They introduce kernel bugs on purpose”

#552

Post by Sanzig »

endisneigh wrote: post #478

Though I disagree with the research in general, if you did want to research "hypocrite commits" in an actual OSS setting, there isn't really any other way to do it other than actually introducing bugs per their proposal. That being said, I think it would've made more sense for them to have created some dummy complex project for a class and have say 80% of the class introduce "good code", 10% of the class review all c…

They could have contacted a core maintainer and explained to them what they planned to do. That core maintainer could have then spoken to other senior core maintainers in confidence (including Greg and Linus) to decide if this type of pentest was in the best interest of Linux and the OSS community at large. That decision would need to weigh the possibility of testing and hardening Linux's security review process against possible reputational damage as well as alienating contributors who might quite rightly feel they've been publicly duped.

If leadership was on board, they could have then proceeded with the test under the supervision of those core maintainers who ensure introduced security holes don't find their way into stable. The insiders themselves would abstain from reviewing those patches to see if review by others catches them.

If leadership was not on board, they should have respected the wishes of the Linux team and found another high-visibility open-source project who is more amenable to the project. There are lots of big open-source projects to choose from, the kernel simply happens to be high-profile.

Re: “They introduce kernel bugs on purpose”

#553

Post by m3kw9 »

rubyn00bie wrote: post #321

This is supremely fucked up and I’d say is borderline criminal. It’s really lucky asshole researchers like this haven’t caused a bug that cost billions of dollars, or killed someone, because eventually shit like this will... and holy shit will “it was just research” do nothing to save them.

So aren’t there tests and code reviews before pushing them to the Stable code base?

Re: “They introduce kernel bugs on purpose”

#554

Post by psychometry »

random5634 wrote: post #284

How does something like this get through IRB - I always felt IRB was over the top - and then they approve something like this? UMN looks pretty shoddy - the response from the researcher saying these were automated by a tool looks like a potential lie.

I have a feeling that methods of patching the Linux kernel is a concept most members of IRB boards wouldn't understand at all. It's pretty far outside their wheelhouse.

Re: “They introduce kernel bugs on purpose”

#555

Post by LudwigNagasena »

I am honestly surprised anything like this can pass the ethic committee. The reputational risk seems huge.

For example, in economics departments there is usually a ban on lying to experiment participants. Many of them even explicitly explain to participants that this is a difference between economics and psychology experiments. The reason is that studying preferences is very important to economists, and if participants don’t believe that the experiment conditions are reliable, it will screw the research.

Re: “They introduce kernel bugs on purpose”

#556

Post by betaby »

mccr8 wrote: post #473
arkh wrote: post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

Being rude isn't going to discourage malicious actors, who are motivated by fame or wealth. If you ran a bank and had a bunch of rude bank tellers, you are only going to dissuade customers, not bank robbers.

Proper analogy would be 'rude SWAT team', not 'rude bank tellers'.

Re: “They introduce kernel bugs on purpose”

#557

Post by andrewzah »

goatinaboat wrote: post #387
rubyn00bie wrote: post #321

This is supremely fucked up and I’d say is borderline criminal. It’s really lucky asshole researchers like this haven’t caused a bug that cost billions of dollars, or killed someone, because eventually shit like this will... and holy shit will “it was just research” do nothing to save them.

It’s just a shame there is no mechanism in the license to withdraw permission for this so-called university to use Linux at all

That is expressly the opposite goal of open source. If you arbitrarily say foo user cannot use your software, then it is NOT open source. That's more like source-available.

Nobody would continue to use linux if they randomly banned people from using it, regardless of the reason.

[side note] This is why I despise the term "open source". It obscures the important part of user freedom. The term "Free/libre software" is not perfect, but it doesn't obscure this.

Re: “They introduce kernel bugs on purpose”

#558

Post by megous »

the_af wrote: post #371
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's definitely killing a mosquito with a nuke, but what are the alternatives? The kernel maintainers claim these bogus commits already put too much load on their time. I understand they banned the whole university out of frustration and also because they simply don't have the time to deal with them in a more nuanced way.

There's a real cost. What's your estimate for going through each of these 190 patches individually, looking at the context of the code change, and whether the "ref counting or whatever" bug fix is real, and doing some real testing to ensure that?

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

That looks like quite some significant effort. Now if most of those fixes were real, now after the revert there will be 190 known bugs in the kernel, before it's all cleaned up. That may have some cost too.

Looks like a large and expensive mess someone other than that UNI will have to clean out, because they're not trustworthy, ATM.

Re: “They introduce kernel bugs on purpose”

#559

Post by capableweb »

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…

In the end, the damage has been done and the Linux developers are now going back and removing all patches from any user with a @umn.edu email.

Not sure how the researchers didn't see how this would backfire, but it's a hopeless misuse of their time. I feel really bad for the developers who now have to spend their time fixing shit that shouldn't even be there, just because someone wanted to write a paper and their peers didn't see any problems either. How broken is academia really?

Post reply on HN