UMN CS&E Statement on Linux Kernel Research
cse.umn.edu
cse.umn.edu
“They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 - April 2021 (1562 comments and counting)
I hope their follow up is as thorough but I want to applaud this, it's a good approach.
The way their statement stands they can investigate themselves and determine they did nothing wrong, we'll have to see what they say down the road.
It is more likely that you just have an administrator that became aware of the issue, they won't make an apology until they understand what happened.
The job of UMN is to get the facts first, and then determine actions. If the OSS community (and others) feel like the actions don't match the facts (or if they feel the facts don't match what actually happened) they can apply their own set of actions.
I think an apology before they've had a chance to review everything that occurred would be rather empty, don't you? "I'm sorry you're upset"?
I far prefer what they've stated they're going to do which is stop the activity they know about immediately, and to review how we got to this point.
If, on the off chance, the professor was being honest about ensuring they weren't wasting anyone's time, and ensuring no bad code made it into the kernel, then the situation becomes a bit more murky. They'd need to go through all of the associated emails both public and internal to validate that.
If on the other hand this is in fact a duck, I would expect them to both to issue a meaningful apology at that point, as well as lay out the steps they've taken to ensure it doesn't happen again (which they've indicated is their plan). And hopefully restore the trust of the OSS community.
When the issue has gotten actual attention an apology to the kernel mailing list might be appropriate, but as someone who has been apologized to many times it all just becomes meaningless, who cares if you say you’re sorry. I care what you’ll do about it.
The best apologies are the ones that are done after some reflection, not under duress, and not purely for reputation.
[1] On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits -- https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
They probably just have a bunch of angry emails to go on at this point and haven’t looked in detail at anything else.
Why do you think that enough of an investigation hasn't been performed in order to understand culpability?
Thay already know what happened and want to learn why it was approved. That was what their comment said.
Take a look at the actual PDF from the researchers, "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits" [1]
[1] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
0: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
Here is Ken Thompson's apropos paper from 1984. [0]
[0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
> Why do you think that enough of an investigation hasn't been performed in order to understand culpability?
We need to make sure to be supportive of people making mistakes and learning from them instead of raising pitchforks for every misstep. Failure is never completely avoidable and responding properly to failure is way more important than never failing.
The "if needed" tells me they aren't sure what if anything is wrong yet. It would surprise me if they have done that much of an investigation in the few hours since they might have learned about this beyond scheduling meetings with involved parties and compiling relevant documents in a folder.
I think they are at the point of having a bunch of angry emails and a few news articles from certain publications. I don't blame them wanting a bit more than that before saying anything.
At least now they’re burning UMN time and not kernel maintainer time.
> Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel.
I'm going to say that the odds are that the faculty member in question is not going to be a faculty member anymore especially if the ban remains in place as the said faculty member probably at best fibbed the leadership before about his research.
https://www-users.cs.umn.edu/~kjlu/
Adjuncts don't have Ph.D students.
Btw, I'm not suggesting you don't believe in any of the above.
Their actions should be rectified since they did wrong - not out of fear of a punishment. When we bring only a specific punishment in as a consequence then the question of how to respond can be shifted over to a "which is worse" proposition which means that the punishment needs to be properly proportioned.
At any rate - I doubt admissions would be appreciably impacted even if they handled this incident extremely poorly - some potential grad students might look elsewhere while most would likely be ignorant of the whole incident.
"Ability to commit to the Linux kernel with my school email" isn't likely to be a major issue for many. It's a non-issue for undergrad work, and even most grad students are unlikely to be affected. Other than this research, only one other person associated with UMN has committed code to the kernel.
This impacts any direct school-sponsored research work, but if some random student wants to write a patch, they'll just do it from a personal address - no kernel committer is going to go do social media stalking of every contributor.
I don't think anyone would notice this ban - it'd just be an odd curiosity and impediment to any student that tried to submit a patch... that is assuming it doesn't hit the main news circuit.... But, if I hear about this on Colbert tonight I'll be amazed.
The fact that the FBI raided Steve Jackson Games[1] over GURPS: Cyberpunk is, I think, completely absent from general public knowledge at this point - even though that incident[2] led to the creation of the EFF which most folks on HN will certainly be familiar with. Notoriety is a fickle thing and no matter how negative the incident is it'll usually either fade into nothingness or give a positive boost to the organization - this is where the concept of "there's no such thing as bad press" comes from. I, at least, am far more aware of UMN now than I was this morning.
2. There's some disagreement over how central this incident was to the EFF's foundation, but from what I've read it was pretty darn central.
You are not looking at it the right way. This is an issue for the President and the Provost because of alumni donations.
When the choice is between firing an adjunct/assistant and not getting a 100k from alumni the adjunct/assistant has no chance.
The CS department care the ability to publish paper about the Linux kernel.
For now I'm assuming that my degree was more than 20 years ago, and things change in that time (most of the professors I remember best are dead...). However this is doubt in my mind.
I'm not the GP. I agree with you, but I feel for you.
The fact that you are worried is a good sign, though!
What if a car or medical device running linux turns out to have buggy mutex locking either due to a malicious commit or a now-hastily reverted commit? As a Linux user of both computers, appliances and vehicles, I am not impressed.
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.
This seems like an entirely appropriate balance of text and emphasis for a statement that is short and to the point. Which is also appropriate and laudable. Typically when an organization says any more, it's to try and do some spin doctoring.
> We take this situation extremely seriously.
I think it’s because the last bit of the first paragraph – the ban – flows onto the second paragraph – the situation.
Once you’ve had the two linked, it’s like one of those ambiguous optical illusions, where you just can’t see the other.
If I were writing that statement, I’d be concerned it looked that had there been no ban, there would be no situation. Said statement doesn’t do that for me.
So, as long as you ignore the formatting they presented it with and decide to read it without it, you can come to a different conclusion?
I don't think contortions such as that to link sentences is fair, nor the fault of the organization that put forth for a statement specifically separating them.
No. It reads that way with the formatting they provided. You can’t take that paragraph break out without putting one back exactly there. It’s refreshingly transparent, and perfect if you expect them not to care about the underlying cause as much as they care about the ban.
> I don't think contortions such as that to link sentences is fair, nor the fault of the organization that put forth for a statement specifically separating them.
It’s not a contortion, it’s just how it reads to me. I’m not taking some deliberately contrarian stance – I was really quite shocked at the multiple comments saying how great the statement was when it inadvertently or otherwise conveyed the very message I believe they should have avoided – the one where they simply do the least they need to do to get unbanned, which may well be closer to the real objective. It’s the difference between being shamed into action and recognising why action is necessary.
I would not want to be the person to have to write such a statement
Exactly. And paragraphs are used to separate concepts and statements into conceptual units. That you're letting a concept and interpretation from one apply to and influence the reading of another as if there is no break is the problem.
> It’s not a contortion, it’s just how it reads to me.
I think you have some interesting ideas of how to read. I don't think that follows necessarily for the majority of other people, and I don't think that's what was intended by the writer.
At he same time, I'm not entirely surprised. This is why writing is hard, and sometimes thankless. Regardless of intention and how clear you think you're being, someone will always read it otherwise. It's just the nature of the medium, to some degree. It can happen through something like this, where you're inferring intent across boundaries where I think that boundary is intended to clearly separate it, and it can happen if they are absolutely literally clear and denounce other stances, because people will read those denouncements as indicators of the opposite, as crazy as that sounds ("The lady doth protest too much, methinks").
I think you're better off taking a separate paragraph for what it usually meant to be. A way to separate statements so they are clearly distinct.
Their second paragraph says they "take the situation very seriously".
What "situation", exactly?
Not once do they talk about getting the ban removed, instead they talk about figuring out why it happened and how to be better at having research done being ethical.
Was the ban the trigger to them (the heads) looking into it ? Of course since they do already have safeguards and review processes in place, this happened despite those, so they're saying they will investigate them to figure out how this project was validated and make sure to strengthen these processes as needed.
The end goal they give themselves in that message is not a ban removal but "safeguard against future [such] issues".
I feel as if we’re discussing two different statements.
> The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.
Here the cause is that "the research method used raised serious concerns in the Linux Kernel community"
Not that it was unethical, or potentially how it was. It’s not that something clearly went wrong. The cause can be read as the response, rather than the action.
> safeguard against future issues, if needed
The ban is the trigger. The review is about to happen, so they really can't talk about its result yet. For all you and me know, said review will say their processes are just fine which I would personally disagree with but it could happen. Then, if there was an issue, they will update their processes, which is the end goal stated.
So your quote:
> the ban is the focus – not what led to the ban
The ban is the trigger that starts it, but the focus, the thing on which they will work, is their process. "Something important happened so we will spend lots of time figuring it out how it could have happened despite our processes made to protect against it" makes it pretty clear the focus, the thing they will spend their time on, is the review of their processes.
> For all you and me know, said review will say their processes are just fine which I would personally disagree with but it could happen.
Agreed. For what it’s worth, I don’t actually think there’s much they can really do besides acknowledge it and make sure their ethics board is competent and consulted.
> the ban is the focus – not what led to the ban
I was talking about the ban being the focus of the statement, as it’s the point at which there’s a clear shift from the situation to the fix. This is unfortunate, because to me it is placing the emphasis on the trigger, rather than the cause.
I believe it could have been written in a way that mentioned the ban, left room to investigate, but made it crystal clear that the community concerns and the ban were not the problem. It makes it feel to me as though their primary motivation to investigate is to get unbanned – which, to be fair, it probably is – rather than to be committed to root out alleged unethical practices. Even if the short-term consequences are the same, it’s a subtle but important distinction.
I suppose it’s a form of honesty, and I could instead embrace its transparency.
The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days".
Without any explicit time frame, holding them publicly accountable becomes trickier. At any point they can just say "we're still investigating" until enough time has passed people aren't paying attention any more.
Note that the companies that do ongoing incident updates on status sites best all do this -- "We will provide an update by 10:30pm PST".
They need to act to get the ban rescinded, they can't just ignore this issue away.
The common case today is that admitting you are due to account for your actions is the same as admitting that you are at fault. I have been denied jobs because I have admitted that to being accountable for my decisions, whereas I got the distinct impression had I simply not accounted for them they wouldn't have cared.
I doubt that - in the other thread, someone noted that the last non-hostile kernel contribution from @umn.edu was in 2014. I don't think they are champing at the bit to get legit kernel contributions merged - or at least haven't in the past 7 years. At this point, it is purely a reputation/PR problem with little urgency - the ban is not blocking anyone's work at the university (except for the suspended research project)
For now I'll accept their apology, but if there is no action in the future I'll retract that.
I expect UMN to move swiftly on this but it’s a large university and may move more slowly than we’d like.
If Mozilla had ties to UMN CS&E you might have had a (tenuous) point, but...
Plus, this has come out in the last 48hrs or so? And you're somehow saying that's comparable to 3 years? Sure, if they haven't issued a further statement in 1 month, 3 months, etc. then you might be justified.
This seems incompatible with the pace of academia, as I have experienced it.
Violating IRB ethics is a very serious issue, and has timelines in place once a complaint is filed. I expect that this statement was intended to be fast, short, and direct because of the time sensitivity.
And this is by definition a matter that will involve a lot of parties. At minimum, as everyone in the chain tries to ensure their ass is covered and how it's not really their fault, because it wasn't really their job to say no to this.
This is the second one.
Instead, the statement is there to prevent journalists from putting "UWN puts the entire internet at risk" on their front page. Instead, it frames the incident into a boring "Students offended the Linux Kernel community while trying to help out by doing security research, we will investigate" story.
To me, it’s like the distinction between offence caused and actually showing some genuine reflection as to why there might be offence caused. This statement, to me, is firmly in the former camp.
I don't really think this is a worthwhile distinction. Personally, it comes off as trying to nanny a process that involves the Linux kernel maintainers and UMN Admins. There's a ban on UMN, probably until they show they can head off ethical issues. The public doesn't need to be sitting around demanding an update in 30 days or less. They'll act when they have confidence in their facts and the outcome, and the Linux community will undoubtedly act in kind.
> I very much welcome feedback from the participants who brought this to our attention: that's why I tagged @gregkh . Obviously, we would appreciate any guidance as to how we can get the Univ. of Minnesota contribution ban lifted.
This is pretty clearly one of their main interests in moving fast here. https://twitter.com/lorenterveen/status/1384954220705722369
The University has to do exactly what they have done and follow up, to keep their reputation.
Saying the researcher is the only responsible of a work that is managed by the university (with things such as probably funds and for sure resources) is just wrong.
You vastly underestimate how much effort and attention was put into writing that “single paragraph” because I promise you it sure does take much.
I can only imagine the other department heads screaming at the head of the, relatively speaking, small CS department.
(Tangentially, it's something that computer people do even more often, and probably with fewer ethics controls. A/B testing, for one prominent example.)
But it's typically only allowed when it's clear that the risk of harm to the participants is pretty much negligible. Which is clearly not the case here. As others have said, it's probably the case that the reason this got past the IRB is not because the research was clandestine, but because the team lied about how it might affect people. And probably also, I'm guessing, the IRB had their guard down because they weren't expecting that particular department to be conducting social science field experiments.
Their ethics committee approved the research, and yet I see no acknowledgement of their responsibility.
Throwing anyone under the bus before there any time to even start asking questions is not what any smart administration should do.
What triggered the ban now is another set of suspicious commits was sent by a graduate student in the same research group.
Definitely not "Minnesota Nice".
> I do work in Social Computing, and this situation is directly analogous to a number of incidents on Wikipedia quite awhile ago that led to that community and researchers reaching an understanding on research methods that are and are not acceptable.
and https://twitter.com/lorenterveen/status/1384966202301337603
> Yes! This was an IRB 'failure'. Again, in my area of Social Computing, it's been clear for awhile that IRBs often do not understand the issues and the potential risks/harms of doing research in online communities / social media.
An interesting question is IMHO who people actually tried to contact in the first round of this getting publicity (and I guess how many did so at all), and if leadership should thus have been aware earlier that there was controversy worth looking into.
https://twitter.com/SarahJamieLewis/status/13848713855379087...
Too bad he's not in a position of power to implement that additional review to CS department research.
They were so proud of their discovery. They didnt think to time what that would take if they went to a printer and changed the text there before a book is printed.
First time they initially skipped IRB review for sending malicious patches to the mailing list, which people do install. (So IRB exemption should not apply.) A top security conference allowed a paper with a broken IRB process, and UMN IRB, when a later IRB exempt request was filed, explicitly allowed this. Bad, bad, and bad.
The latest Linux incident seems like a repeat by the same CS dept, advisor, student, & presumably, UMN IRB. No naivete excuse anymore, this is now business as usual.
The bigger fail to me is the UMN dept head + IRB, and the security conference review process around IRB norms. Especially damning that it's a repeat of the same IRB mess. IRB exemption matters a lot for practicing scientists, and leadership tolerating this stuff is what will get it taken away for everyone else.
Fool me once..
It's not clear that they're doing the same thing--we don't know that these recent patches are deliberately bogus. See this comment with clarifications from the other post: https://news.ycombinator.com/item?id=26890583
Most charitably, the tool makes changes maintainers largely don't care about -- see the revert reviews that characterize past acceptances as being rubberstamping of irrelevant patches to irrelevant code -- so this just violates basics like informed consent by not disclosing what's happening. Maintainers had to figure out the nonsense, and instead of declining a second round of undesirable non-opt-in participation, banned. What would normally happen is the patches would be tagged w/ the R&D tool, so people know they're part of an experiment, and can ignore / ask them to stop / consent through action.
Less charitably, it is a DoS attack on reviewers, and who knows what else is in here.
Either way... not good.
Instead, what bothered me immensely is the way the PhD student handled that interaction: immediately claiming "bias", "slander", playing "victim", etc... I don't know if he learned such a way to communicate from his professors, other students at the CS&E department, or UMN environment in general, but it's very bothersome to me. Such way to communicate precludes constructive (and perhaps heated) exchange of ideas. I think people like that should be nowhere near important CS/EE projects.
I think this can be an interesting topic in itself, how those trigger words and victim playing can get you through code reviews faster. It's certainly true in my company...
Of course, it's also possible that he is just gaslighting Greg and actually was doing the same kind of "research" as other people did before.
I think that UMN will get to the bottom of it - it will be pretty clear to them what kind of research he was doing, and whether he represented himself honestly.
https://www-users.cs.umn.edu/~kjlu/papers/eecatch.pdf?fbclid...
Still, given that he is 4+ years into a PhD (after a Masters), and has published on this topic before, his first deflection is "We are not experts in the linux kernel" seems disingenuous - kinda like "Hey guys, I'm not malicious, just not good at my job."
[1] https://en.wikipedia.org/wiki/Institutional_review_board
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 clear that the institute cannot be trusted until the institute takes decisive restorative action. By banning the University, you are saying "we no longer trust you in your authority as an institution until it can be made clear that this isn't a systemic problem."... you are not saying "every single person at the University is terrible" as it was framed by some commenters in the other thread.
This is why, in any broad case, it's so upsetting when an institution of any variety doesn't take clear responsibility for the behavior and actions of its members or representatives (take for example the police, or the federal government). When that is true, the behavior of any member of that institution should be subject to scrutiny and distrust. It's not a complicated social phenomena.
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.
"If a doctor commits malpractice, immediately disregard all medical advice given to you by any other doctors at their hospital"
Perhaps the hospital actually has excellent oversight and it is just that the evil doctor is exceptionally clever at avoiding it. But, Occam's Razor says that is a poor bet.
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 reverted for now for triage (not permanently).
For the linked patch, I would judge it possibly malicious as it leaves the identified vulnerability in the kernel for later exploit by the attackers, namely, the UMN research team.
I'm disappointed at seeing hackernews jump on this mindless mob justice like other sites would.
Having your patch reverted pending review is hardly punishment. Calling this mob justice is an insult to both mobs and justice.
edit: actually not even the develop I think https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... It is just another branch? I am not familiar with the jargon
No word from DHS Cybersecurity yet.
[1] https://www.google.com/search?channel=fs&q=university+of+min...
The ban could affect donations from alumni or corporations.
(I'm not the user you're replying to.)
Nothing, frankly. But why can't any agency tell them that red-teaming is a good idea? DHS Cybersecurity is interested in keeping Linux secure, so it will tell them.
There's no "American exceptionalism" in the parent comment, just that the US is a pretty influential country and it may want to give its opinion.
What else can I do than revert the lot?
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 point assuming bad faith for all UMN patches and reviewing them all before allowing them to stay in. (Or if they get reverted by default, someone else can manually apply them after they go through strict review.)
Fool me once, shame on you, fool me twice....
This seems like a gross overreaction to three commits that didn't even make it into mainline. Especially when done for commits years before the "research" was done. But I suppose nobody can miss a chance to let loose a little outrage
Best to spend time auditing every commit in the kernel for bugs rather than grandstanding over the commits from one university's members.
It's famously hard to distinguish malice from incompetence, but I don't think assuming bad faith is out of line here.
[1] https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...
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 MIT, CMU, and Stanford combined. Jeff Dean is a UMN alumni. I am too. The fraction of this set that is actually associated with the shady research is tiny.
It seems to me like the kernel maintainers are at best wasting a whole ton of their own time on this, and at worst re-introducing a wide range of bugs that UMN contributors had fixed over the years. A real "cutting off your nose to spite your face" situation IMO.
And we didn't take any action until another series of suspicious patches started getting sent for review from a graduate student from the same group. At which point, we have a unrepentant professor who has gotten rewarded by a paper at IEEE S&P, and being invited to serve on the PC of the IEEE S&P next year, and an apparently apathetic, toothless IRB at UMN. I can see people criticizing us if we hadn't taken action.
That said, there were hundreds of reverted commits and many of them were fixing real security bugs. In particular, the same security researchers that did the questionable experiment has also contributed many real bug fixes.
In other news, we just learned that any half-decent security agency has already injected their own vulnerabilities and back-doors in OSS.
They got caught and had all their contributions reverted.
Seems like the UMN "researcher" was doing this over and over; the more times you do it, the more likely you are to get caught.
It would be interesting if someone found bad stuff in the kernel, but pet of the org structure makes this hard.
Trust is an important social contract since it lowers the cost of social transactions. But trust takes a long time to earn and can be lost in a flash.
If you do inject vulnerabilities you need to assume your adversaries will find, catalog, and script an exploit for it. And you risk your reputation loss if you do get caught. So I'm sure it has happened, but I bet not that often.
We did not learn that today, but we still assume it.
Btw. the professional agencies have their vulnerabilities injected probably way down in hardware level. Intel ME etc. and or even more bare to the metal.
It's not innovation or research, or even progress, it's actively destabilizing and subverting a targetted community that a huge part (even majority) of the economy depends on the integrity of. This is a hawkish view, but in a challenging cultural moment, their activities are very difficult to be charitable about.
I wish I could be on the researchers' side, as I am both Chinese and an alum from UMN. But No - wrong is wrong.
There are weasel words in this statement that make it unclear and the researchers have been really dishonest already. But! If it's true that their research has never made it out of email chains then it does seem like the reaction is a bit disproportionate to the damages here.
https://lore.kernel.org/lkml/YIBMKSovJumS79SR@pendragon.idea...
e: Not getting pulled into a maintainer tree isn't enough to be safe about what was posted to a kernel mailing list. People can (and testing scripts blindly do) grab and apply patches on the mailing list.
This story reminded me of facebook experimenting on their users to control their emotional state (but they said users were volunteers because "terms of service"...)
“They introduce kernel bugs on purpose”
There's value in setting down the pitchforks.
and Kangjie Lu's response: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
> 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 divine right to carry out this “research” no matter what.
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"
What's weird is of course that they didn't tell anyone. In the fairly analogous situation of "white-hat hacker" penetration testing, the penetrators have authorization from either someone (fairly high up in) the security department of the organisation to be tested, or if that whole department is being evaluated someone even higher than that; without that authorization it's not white-hat testing but just black-hat cracking. They should have privately contacted mr Kroah-Hartman, and/or Linus himself, beforehand and asked if they were amenable to this. Then they could have had the option to accept and be in on it, not comment on but silently monitor the patches in question, and at the end of the experiment reveal the results to their fellow maintainers and revert any specific patches -- which they would have been continuously kept informed about out-of-band -- that had made it through review.
Provided of course that they, Greg K-H or Linus or whoever, would have been comfortable with temporarily deceiving -- or letting be deceived -- their fellow maintainers, of course. Or, well, even if they weren't exactly "comfortable" with it, seems to me there's a chance they might have gone for it because of the valuable knowledge it would have gained the community. The "reveal" afterwards, coming first from one of these trusted people, would probably go down a lot better in the maintainer community than it did as this secret external attack.
> 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.
Have they ever heard about carbon offsets? How about finding/performing work that offsets the abuse of time of the maintainers involved? (Hint: it's not too late to do this to show you really are sorry. You won't be trusted at first but it's the right thing to do.)
It sucks that the maintainers have to play cleanup, but at least it will hopefully lead to a positive outcome.
> The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.
The research method _approved by the University's internal authorities_.
And the associate department head labelling it a failure of the review process: https://twitter.com/lorenterveen/status/1384966202301337603
"_or publicity_"
I think that says enough about the U of Mn.
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.
They will release a statement, right?
That they did that in the past is clearly unethical and was generally a shitty thing to do, but this group also seems to do technical security research. That the student (allegedly) trusted his static code analyzer so much that he did not care to verify its findings doesn't speak for him, but Hanlon's razor may also apply here. Just banning that student (if he keeps submitting technically inferior patches) should be enough imho.
I am very curious to hear who approved wasting the time of Linux kernel developers, many of whom are volunteers, with this excuse for academic research.
But it means the regularly 'security' research does ethically questionable stuff.
IRBs exist because of legal risk. If parties harmed by unethical computer science research do not litigate (or bring criminal complaints, as applicable) the university practices will not substantially change.
Uhh... they didn't know what their own employees were doing?
Don't most universities have review/approval procedures before people can do experiments or studies?
This is purely a damage mitigation strategy. If we give them more credit than they really deserve, the department and IRB were severely negligent.
Now, when a Dean puts up a webpage... things just got serious.
For now it can be a "something CS is taking care of, but you need to be aware of it in case they don't".
cc/ dang
Though I suspect periodic searches for recent mentions of dang's username in comments are also employed. It's a matter of what's most efficient and convenient for the team, and what community practices have evolved.
But opposite because dang is helpful and nice.
https://news.ycombinator.com/item?id=20652146
Some of this stuff will eventually get open-sourced and/or integrated into HN for everybody.
fhars helpfully changed the title.
I expect the department and university to perform a thorough investigation, and respond with decisive action afterwards. Not the other way around.
... absolutely. Perhaps people liked the flavor.
I am snarking about the apparent disconnect between the previous suspect activities that have apparently not yet resulted in that kind of oversight thus requiring this kind of sanction from the kernel team. I am snarking because the "poor us" these folks already pulled on LKML shows any debate is pointless, as this is firmly a matter of identity politics already.
In other words, yes, some people do prefer that flavor.
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.
I have investigated, as far as I feel I need to cast judgment. I'm just some hick on a hill in the woods. My censure amounts to a ghosted bit of snark.
If the people who employ these folks make snarky comments about them, that's no more meaningful. If they choose to examine the actual evidence of the behavior at issue here, they might find it upsetting as i do... or hell i dunno there's many reasons they might not. I can't imagine what explanation there might be for this behavior but i'll allow there might be one even I could agree with...
but honestly, it seems like valuable research to me. it's unfortunate that it took some time away from busy kernel developers, and it's unfortunate that it ultimately makes the project look worse...
...but isn't that supposed to be part of the promise behind open source? it wouldn't surprise me if i learned that management of private orgs hire security firms to do this sort of thing. where does that come from in foss land, other than the ethers of others tinkering, researching and experimenting?
i think this whole calling for the researchers heads business is overblown. i read their paper, it looks like they approached the situation quite ethically to me.
i'll tell you one thing, it has shaken my trust in the oss kernel development model as it operates today, and honestly that seems like maybe a good thing?
how many companies are literally printing money with the linux kernel? can't they throw a few bones at helping beef up code review and security analysis?
You can try to detect it before it happens, but very often you won't catch it until after it's landed in the source code repository, and some cases, it'll actually make it out to customers before you notice.
It's true for proprietary code; it'st true for open source code; it's true for x.509 CA certificates[1]. We should still do the best job that we can, if for no other reason that there are plenty of zero-days which are introduced by human error, never mind by malicious actors.
[1] https://www.thesslstore.com/blog/final-warning-last-chance-t...
but if a set of academic researchers try it on the linux kernel, nothing changes and then there's a bunch of internet drama with people calling for them to be fired because why?
honestly, i've believed in oss since i encountered it in the early 90s. but this is making me start to reconsider proprietary software again.
At least with OSS everyone can audit the code, and run their own security scanners on the open source code. If you think that somehow proprietary software is magically protected against the insider threat, you're kidding yourself. Even the NSA couldn't protect against an inside like Snowden.
sounds good to me! (j/k, sorta)
except here's the key point, and here's where i think the issue is: "...obviously Microsoft's hiring and software engineering practices could be improved"
...this isn't about the people involved being bad at what they do, or them being bad people, or the project being silly in some way. it's about the people, the process they use and the project itself meshing together in an unfortunate way to create a real vulnerability for society. linux is no longer a hobby project. every effort can and should be made to ensure that it is secure as possible as linux is now so pervasive that defects can literally have life and death consequences.
this isn't about some maintainer failing to catch security bugs, this is about the growing influence and criticality of the project and the vulnerability of the project to security bugs, both technically and culturally.
the only real human failure is seeing egos get in the way of improvement.
who am i to be making these arguments? i'm just a nobody. a nobody who has to live in a society that is increasingly being built on this stuff...
You'd very likely would have been able to get code past them even if you told them that there are attempts coming and got their approval.
Given that, you need a good justification why that wasn't enough for you, and what value you truly added over what already was the common view on the issue. But at least we got valuable recommendations from their paper, like "there should be a code of conduct forbidding malicious submissions" and "you could try vetting peoples real identities". (I guess they added to the last bit, giving additional data points that "works at a respected institution in a related field" is not sufficient to establish trust)
it's unfortunate that something happened in the project that cost the maintainers a lot of hours, that comes with the territory of working on important software, i'd argue.
i don't want an espionagetastic fundamentally untrustable and inescapable computing hellscape, airplanes falling out of the sky, cars crashing or appliances catching fire because it "already was the common view on the issue."
if the paper raises awareness of the issue, it's a good thing for society, it seems. if money materializes to do background checks on kernel contributors, that seems a good thing, no? if resources materialize for additional scrutiny, that seems a good thing, no?
if anything, the "common view" / status quo seems terribly broken, as demonstrated by their research. while what they've done is unpopular, it seems to me that ultimately the project, and the society of which large chunks it now powers, may be better of for it in the long run...
what's the non-controversial alternative? alerting the organization before they do it? that doesn't work. that's why scientists do blinding and double blinding.
if you mean something else, then i'm missing parts of this (really complicated) debate.
> If you wanted to know if the kernel review process is able to reliably catch malicious attempts you literally could have just asked the kernel maintainers and they'd told you that no, review can't go that deep. Or looked at non-malicious bugs and observed that no, review does not catch all bugs with security implications.
> You'd very likely would have been able to get code past them even if you told them that there are attempts coming and got their approval.
If you want to know that the process isn't catching all attacks, that should be all you need. For the second case, getting patches past a warned maintainer is harder and should be even better evidence of the problems of the process, without any of the concerns. There is a wide range of options to learn about code review, and what they did was one of the extreme ends - just to find "yes, what everyone has been saying is true". And then not putting in the work to make amends after it becomes clear it wasn't appreciated, so now this other student got caught in his advisors mess (assuming the representation of him actually testing a new analyzer and not being part of a repeated attempt to introduce bugs is true - the way he went about it also wasn't good, but way less bad).
But you don't get splashy outrage, and thus less success at "raising awareness" with people that didn't care before, which is what your comment seemed to argue for.
the reason for doing it, is basic quality science. it's proper blinding.
the result is raising awareness, which if it leads to more scrutiny and a better and more secure linux kernel, seems to be a good thing... in the long run.
i mean, i get it. a lot of this security stuff feels a lot like gotcha qa, with people looking to make names for themselves at the expense of others. and yeah, in science, making a name for yourself is the primary currency...
but honestly, they ran their experiment and it worked, uncovered an actual, not theoretical, vulnerability in an irrefutable way, in a massive chunk of computing infrastructure that powers massive chunks of society.
papers like this one can have a lot of potential in terms of raising funds. this is the sort of thing that can be taken to governments, private foundations and public corporations to ask for quite a lot of money to help with the situation.
if the developers were working for a private company, there could be a similar loss in time for a similar exercise that could be approved by company leadership, no? if tim cook ordered an audit and didn't tell anyone, wouldn't there be developers at apple feeling the same way?
look, i get it, it's unfortunate and people feel like it's a black eye... but it's also a real issue that needs real attention. moreover, linux is no longer a hobby, it is critical infrastructure that powers large chunks of society.
This was not disclosed up front, and at this point, it is impossible to tell whether he was creating an incompetent, no-where-near-state-of-the-art code analyzer which gave bogus results, and then was too incompetent to realize it was bogus, and instead submitted the patches to kernel developers asking us to be his QA, without disclosing that this was what he was done ---- or this could be another human experimentation where they are trying to see how gullible the patch review process is at accepting bogus patches.
We have no idea, because his research group has previously submitted patches in bad faith, and UMN's IRB board gave it the A-OK ethics review. At this point, the safe thing to do is to assume that it was also submitted in bad faith.
You generally must have consent from the people being experimented on within the US.
There are all sorts of rules when doing an experiment on humans in the US, and they generally require consent.
To be clear: I do not know all the facts in this case, and I'm not a lawyer. But I'm glad that GregKH took the "immediate ban" step, that seemed like the safest course of action with the info he had. I think experiments to see "what can slip through review" could be really valuable & important, but when humans are being experimented on, you normally need their consent first.
As as study of a group activity it seems inapplicable to a psychology department, though that could be a bias on my part.
Messing with Linux is messing with that sensitive stuff, which means messing with important people and organizations. That is something that is very hard to get away with.
That guy just got himself into a legal supernightmare.
If someone is running a stock exchange on Linux and a guy introduces vulnerabilities on purpose, I am sure that person will be pretty upset and pursue litigation.
The only way I could see this getting forgiven is if every party that could have cancelled the project is forcibly removed from holding any position of employment or enrollment at UMN, going all the way up to the head owners and managers of the entire university.
That is nothing like how research operates at a university like UMN. At a research university, typically the only person that actually must sign off on a computer science experiment is the grad student / professor actually doing the work. Graduate students frequently clear their work with their advisors first, but even that isn't strictly required. A small amount of work technically requires IRB approval, but unless what you're doing is very obviously human subject research, it is unlikely anyone would even notice if you went rogue and ignored it.