Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

101–110 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#101
post #86

Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…

Agreed, in fact the review process worked and now they are going to ban all contributions from that university, as it should be. I think it all worked out perfectly

Re: “They introduce kernel bugs on purpose”

#102
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 extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...

The university reviewed the "study" and said it was acceptable. From the email chain, it looks like they've already complained to the university multiple times, and have apparently been ignored. Banning anyone at the university from contributing seems like the only way to handle it since they can't trust the institution to ensure its students are doing unethical experiments.

Re: “They introduce kernel bugs on purpose”

#103
post #33

Should've at least sought approval from the maintainer party, and perhaps tried to orchestrate it so that the patch approver didn't have information about it, but some part of the org did. In a network security analogy, this is just unsolicited hacking VS being a penetration test which it claims more so to be.

This is no better. All it does is increase the size of the research team. You’re still doing research on non-consenting participants.

Re: “They introduce kernel bugs on purpose”

#104
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 extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...

The University approved this research. How can one trust anything from that university now?

Re: “They introduce kernel bugs on purpose”

#106
post #61

The project is interesting, but how can they be so dumb as to post these patches under an @umn.edu address instead of using a new pseudonymous identity for each patch?!? I mean, sneakily introducing vulnerabilities obviously only works if you don't start your messages by announcing you are one of the guys known to be trying to do so...

That's kind of the rub. They used a university email to exploit the trust afforded to them as academics and then violated that trust. As a result that trust was revoked. If they want to submit future patches they'll need to do it with random email addresses and will be subject to the scrutiny afforded random email addresses.

I doubt an university e-mail gives you significantly increased trust in the kernel community, since those are given to all students in all majors (most of which are of course much less competent at kernel development than the average kernel developer).

Re: “They introduce kernel bugs on purpose”

#107
post #28

Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?

Not sure why you think they proved that. Human review was done on the same day the patch was submitted and pointed out that it's wrong: https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie...

Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!

Re: “They introduce kernel bugs on purpose”

#108
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 extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...

They reported unethical behavior to the university and the university failed to prevent it from happening again.

Re: “They introduce kernel bugs on purpose”

#109

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.

It may be unethical from an academic perspective, but I like that they did this. It shows there is a problem with the review process if it is not catching 100% of this garbage. Actual malicious actors are certainly already doing worse and maybe succeeding. In a roundabout way, this researcher has achieved their goal, and I hope they publish their results. Certainly more meaningful than most of the drivel in the acade…

By your logic, you allow recording people without their consent, experimenting on PTSD by inducing PTSD without people consent, or medical experimentation without the subject consent.

Try to introduce yourself in the White House and when you get caught tell them "I was just testing your security procedures".

Re: “They introduce kernel bugs on purpose”

#110

I guess someone had to do this unethical experiment, but otoh, what is the value here? There's a high chance someone would later find these "intentional bugs" , it's how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway

> but nobody thought so anyway A lot of people claim that there's a lot of eyes on the code and thus introducing vulnerabilities is unlikely. This research clearly has bruised some egos bad.

> A lot of people claim that there's a lot of eyes on the code

And they are correct. Unfortunately sometimes the number of eyes is not enough.

The alternative is closed source, which has prove to be orders of magnitude worse, on many occasions.

Post reply on HN