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

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

Post reply on HN
Print view View original

261–270 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#261

Post by the_snooze »

alisonkisk wrote: post #246
debaserab2 wrote: post #83

Earlier quoted context omitted.

Yeah, it gets even worse: https://twitter.com/SarahJamieLewis/status/13848713855379087...

That's shameful of the IEEE committee that approved the paper.

Absolutely. I think this is more of a failure of the IEEE Security and Privacy program committee (PC) than that of the university. The chairs should have desk rejected it on ethical grounds. Failing that, at least one of the reviewers should have noticed this was fishy and raised the alarm. And failing that, someone in the full PC meeting should have been like "whoa, hol up." (though this last failure could be partially explained with PC meetings now happening online instead of in person, so less engagement)

Re: UMN CS&E Statement on Linux Kernel Research

#262

Post by julianlam »

WrtCdEvrydy wrote: post #109
Doctor_Fegg wrote: post #68

Earlier quoted context omitted.

The sheer entitlement of this: > 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 precious time. We had carefully considered this issue, but could not figure out a better solution in this study. Here’s a better solution: don’t do it. You do not have a d…

I blew up at someone in the different thread and got roasted... but I don't understand why you couldn't talk to the team reviewing the patches... Seriously, tell them "we're going to send 10 patches for security review, don't merge any of them, tell us if it's good or not"

I don't want to defend the researcher, but that's not a solution. The way it was done was at least blinded (even if ethically wrong).

Re: UMN CS&E Statement on Linux Kernel Research

#263

Post by j16sdiz »

munk-a wrote: post #223
oivey wrote: post #195

Earlier quoted context omitted.

Maybe practically this doesn’t prevent most students or faculty from doing anything, but it is a huge reputation problem. How many universities (or organizations in general) are banned from contributing to the Linux kernel? When people search for why, they’ll find a research group basically screwing over their collaborators and anyone else who uses Linux. That that exists at UMN could be viewed as a serious cultural…

I feel you're overvaluing the ability to contribute to the linux kernel - this is definitely a bad thing and the university should work to correct the situation. But when I was looking at colleges and universties (for undergrad - I didn't pursue a grad degree) I didn't ever ask if the university was blacklisted by any open source organizations. I don't think anyone would notice this ban - it'd just be an odd curiosit…

> I feel you're overvaluing the ability to contribute to the linux kernel

The CS department care the ability to publish paper about the Linux kernel.

Re: UMN CS&E Statement on Linux Kernel Research

#264

Post by [deleted] »

kentonv wrote: post #177
tytso wrote: post #78

Earlier quoted context omitted.

gregkh sent a 190 patch series to revert all of the "easy" UMN reverts, pending review. People are now looking at the patches and saying things like, "that's one OK, don't revert". There are another 68 commits which did not revert cleanly, in some cases because they were later fixed up, already reverted, or some other patch has touched those lines of code. This will require further manual work. We basically at this p…

Temporarily banning UMN until they can get their IRB act together makes sense, but wholesale reverting every commit ever made by a UMN e-mail address -- whether affiliated with this research or not -- seems kind of extreme? I'm not sure how many people here understand this, but the University of Minnesota is quite large, over 50,000 people. That's comparable to the entire population of Palo Alto and is larger than MI…

[deleted]

Re: UMN CS&E Statement on Linux Kernel Research

#265

Post by seoaeu »

toss1 wrote: post #55
earthscienceman wrote: post #10

Earlier quoted context omitted.

Anyone saying that it was a bad idea to ban the entire University isn't looking at the big picture. I look at it from a very philosophical standpoint: The entire idea of an academic (research) institution can be summarized as "an entity representing a group of trusted people who act in good faith of that institution". The moment one of your researchers acts in bad faith, or shows that they cannot be trusted, it's cle…

Yup, it had to be dealt with on an org level, not only the offending person/group. Although it isn't the medical profession, the same directive should apply to research: "First, do no harm." This deliberate poisoning of OS projects without prior permission to 'test the security' violated that big time. I'm astonished it got past any ethics review, indicating to me that there likely was none.

Ah, but you're missing the directive that medicine doesn't have:

"If a doctor commits malpractice, immediately disregard all medical advice given to you by any other doctors at their hospital"

Re: UMN CS&E Statement on Linux Kernel Research

#266

Post by capsulecorp »

kapp_in_life wrote: post #253
unanswered wrote: post #213

Earlier quoted context omitted.

Except that patch is clearly BS! You can't patch a double-read vulnerability by checking for a capability; that's not a thing that works. So either the description is wrong, or the patch is wrong, or both. And the point of the reverts is that the kernel maintainers don't have the unlimited time that would be necessary to re-review all of these questionable patches for probable malicious underhanded C, so they are rev…

You don't think reverting a patch from someone whose only relation is working(worked?) at the same university as the advisor initially responsible for the security "research" is overkill? If the goal is to prevent security bugs in mainline then maybe haphazardly reverting everything that doesn't conflict and fixing it later isn't the best approach. I'm disappointed at seeing hackernews jump on this mindless mob justi…

Its a completely reasonable response. I'd say your point of view is the mindless one.

Re: UMN CS&E Statement on Linux Kernel Research

#267

Post by seoaeu »

dleslie wrote: post #247
detaro wrote: post #231

Earlier quoted context omitted.

I mean, the "publicity" here was the paper announcement and some arguing on Twitter involving the professor, that's not automatic "department leadership needs to look into this" material. If the IRB didn't find anything, it also didn't have a reason to involve leadership. As said elsewhere, something should probably have been noticed at that point, but they intend to look into that. Seems fair, as long as that's what…

I'm not able to give them the benefit of the doubt; or at least, if they are so inept they should be rejected by the scientific community. Imagine this: "After thorough research, we discovered that we were able to cause the deaths of numerous individuals by knowingly constructing an unsafe bridge and having it pass municipal inspection." That's the level of unethical research that the U of Mn approved.

The department leadership never approved the research. Why does no one seem to understand that universities don't work like corporations? You never have to get your research ideas approved up the chain of command. You just start working on them (after running them by an IRB if you think that's necessary).

Re: UMN CS&E Statement on Linux Kernel Research

#268

Post by Zarathust »

dpwm wrote: post #81
Zarathust wrote: post #47

Earlier quoted context omitted.

If they really care about being banned, they'll have no choice but to follow thorough

I’ve read and re-read that statement, and it seems like the ban is the focus – not what led to the ban. I get that they may not know anything, but there are other ways to word that without admitting liability, making it seem less like the focus is on the ban and more on the allegedly shady stuff.

My take on that is that it's up to the kernel maintainers to unban them. If they end up the investigation with: "Yeah, that was bad but we won't do anything about it", it's unlikely to get the banning side to move an inch.

Re: UMN CS&E Statement on Linux Kernel Research

#269

Post by infogulch »

h2odragon wrote: post #259
infogulch wrote: post #244

Earlier quoted context omitted.

Your insinuation that I think there may have been no wrongdoing is unjustified and insulting. The behavior has been halted from both sides, no more active harm is being done; your urgency is misplaced. Somehow you think it's unreasonable to investigate before casting judgement -- as if justice itself is invalid if not met out at the pace of a twitter mob's attention span.

I beg your pardon; i do not insinuate anything on your part: I agree with you. Investigate this and see if there's been any wrongdoing or just honest mistakes and correct those that were made... at the professional, academic level; that certainly seems proper. I am snarking about the apparent disconnect between the previous suspect activities that have apparently not yet resulted in that kind of oversight thus requir…

Thank you for clarifying. I agree that the researchers' initial response was comically out-of-touch, and can now see the perspective where your snark satirises their statements (deservedly so).

I apologize for my aggressive tone, perhaps I should take my own advice and be more inquisitive at first when replying to someone. :) I think the best version of my previous reply would have been something like: "It seems like you think it's unreasonable to investigate before casting judgement." which still expresses my (confused) perspective fairly well but leaves you with a more comfortable space to clarify.

Re: UMN CS&E Statement on Linux Kernel Research

#270

Post by seoaeu »

andy_ppp wrote: post #203

Can someone explain why engineering of bugs into products is bad but hacking to find software defects is good. I think trying to do this sort of research is good because obviously it presents a vector for malicious actors we should all be aware of. It’s good that the Linux team found these issues but I don’t see the intention as being any different than any other kind of hacking, just like some organisations will sen…

What's valuable is fixing security issues. So if you "hack" some system and then provide either patches or useful guidance on how to eliminate a vulnerability that is helpful. By contrast, if a security issue is already known/is being addressed, exploiting that vulnerability just causes problems and wastes people's time.
Post reply on HN