LWN: Comments on "A statement on the UMN mess"

What if there actually was a malicious contributor?

marcH — Wed, 28 Apr 2021 07:32:18 +0000

Thanks: there seems to be a lot of discussion about two students and one university and not much about how anyone else from anywhere else can do the same again.

> What if there was a malicious entity trying to get their vulnerabilities in? They would use fake identities and definitely would not tell about it after patches are okayed. All of the discussions around the blame would be irrelevant (it's just a burned fake identity once discovered).

Drop the "if": any half-competent three letters agency should be doing this already. If they are not then they are simply not doing their job.

https://www.theguardian.com/commentisfree/2020/dec/23/cyb...

> If anything, the US’s prioritization of offense over defense makes us less safe. In the interests of surveillance, the NSA has pushed for an insecure cellphone encryption standard and a backdoor in random number generators (important for secure encryption). The DoJ has never relented in its insistence that the world’s popular encryption systems be made insecure through back doors – another hot point where attack and defense are in conflict. In other words, we allow for insecure standards and systems, because we can use them to spy on others.

Re: getting at the data

tbird20d — Mon, 26 Apr 2021 18:58:14 +0000

Well, the UMN researchers have stated that they don't want to provide details about the messages so as to avoid implicating any individual maintainers. That's actually a point in their favor from an ethics standpoint, in my opinion. Of course that's against a background of poor ethical considerations for the study methodology in general. Personally, I don't think getting access to the e-mail exchanges on 3 suggested patches is going to tell us much about problems with maintainers accepting malicious patches. But if desired, maybe there is a way of disclosing the information to a trusted community entity (for example the TAB), and having that group evaluate the data in private.

But that's only if the community sees value in spending more time on this line of security research, which may not be the case.

A statement on the UMN mess

viro — Sun, 25 Apr 2021 14:09:38 +0000

"Real steps" as in "we need to do something, this is something, let's do it"? You (and this apology of theirs) seem to be treating that as a PR problem; what I want is to reduce the odds of crap getting in.

And their apology completely misses the point on lack of data. Frankly, it's starting to look like their experiment design had been inexistent and the lack of IRB approval is just a symptom of that.

I want to see their dataset and protocol published. The problem of inconsistent review quality *is* real and their dataset would be interesting to go over and try to tease the contributing factors out of it. With what they'd published it's impossible to do. They provide some stats out of their experiment and proceed to proposed mitigation. With reasoning being pretty close to "well, crap can get in, these tools might catch the specific genre of broken patches we'd used, so go use those tools". With not so much as a discussion of the relevance of the nature of breakage in patches to the odds of successful evasion of review, which is curious, since the examined mechanism of evasion would seem to rely a lot upon the commit message.

The thing is, it's impossible to get any useful analysis out of what they'd published so far. Ideally we'd need the message-ids of all postings that had been part of their experiment; timestamps and contents can be recovered from that. Run termination conditions, etc. are also interesting, but I'm not holding my breath on those.

A statement on the UMN mess

clump — Sun, 25 Apr 2021 12:52:10 +0000

I'm suggesting UMN takes real steps to address the matter. They could do something, anything, toward rebuilding trust and it doesn't have to be onerous on contributors. It could just mean "Hey, we're not experimenting on you" or "We did something to validate that these patches are legitimate".

Since this discussion, Kangjie Lu has apologized. It's worth a read:

* All the other 190 patches being reverted and re-evaluated were
submitted as part of other projects and as a service to the community;
they are not related to the “hypocrite commits” paper.
* These 190 patches were in response to real bugs in the code and all
correct--as far as we can discern--when we submitted them.
* We understand the desire of the community to gain access to and
examine the three incorrect patches. Doing so would reveal the
identity of members of the community who responded to these patches on
the message board. Therefore, we are working to obtain their consent
before revealing these patches.

Lu mentions the very real concern that you and others posted, which is the need to separate the experiment from unrelated past and future work. Kudos. What is UMN going to do to rebuild trust?

What if there actually was a malicious contributor?

flussence — Sun, 25 Apr 2021 01:30:32 +0000

Most of us here are familiar with that story, but I should point out the git command only shows a tiny fraction of it: what eventually got through. The numerous "edited" remarks in the S-O-B lines hint at something deeper, but I don't think anyone wants to go trawling the lists to count how many of those rejected patches simply wasted (person-months of) everyone's time.

The takeaway from this is the kernel devs already *can* recognise garbage code. We don't need a scientific paper to know that, we need to get better at handling - for lack of a better adjective - sociopathic *people* before they reach a critical mass of disruption like this.

A statement on the UMN mess

pabs — Sun, 25 Apr 2021 01:17:14 +0000

Employees should push back against abusive employment contacts, including ones that say the employer owns copyright on your work:

https://sfconservancy.org/contractpatch/

A statement on the UMN mess

viro — Sun, 25 Apr 2021 00:08:09 +0000

Regarding the static analyzers in general... IME they are best used to find potentially fishy places, so those who use those could see the low-hanging fruit for code audit. Having them generate patches is a bad idea - the task is not quite AI-complete, but in practice you can't let them run unfiltered (as these examples show) and submitter's filtering throughput ends up being the bottleneck; automating the generation of patches doesn't help - it's not the rate-limiting stage.

A statement on the UMN mess

bfields — Sat, 24 Apr 2021 21:54:20 +0000

"Seriously, check that commit."

This, yes:

https://lore.kernel.org/lkml/20210407000913.2207831-1-pak...

and this one:

https://lore.kernel.org/linux-nfs/20210421225240.GA117423...

was just as odd. I'd be curious to hear what happened. Agreed that they should have followed up.

Half the world seems too angry to think straight at this point.

"As for the missing data, I'd been referring to the recent paper on UAF injection and experiment described (FSVO) in there."

Understood. It doesn't give me much confidence that they're not willing to list those patches.

A statement on the UMN mess

mfuzzey — Sat, 24 Apr 2021 21:21:19 +0000

>That's pretty much what any commercial organisation would require of its employees to contribute to FLOSS

I disagree, sure you need to get permission from someone in authority within your company to contribute to FLOSS as part of your job but that doesn't mean someone else in the organisation signing each and every of your patches.

In fact I think patches,with SOBs by people in the same organisation tend to be frowned on as they tend to be considered to add little value.

A statement on the UMN mess

viro — Sat, 24 Apr 2021 16:48:02 +0000

Care to show me a (current) example among the (current) high-volume contributors?

A statement on the UMN mess

pizza — Sat, 24 Apr 2021 16:37:12 +0000

> Oh, _lovely_. Let me get it straight - you seem to be suggesting that
> 1) school should own whatever students might write

Here's UMN's policies about this. They seem to be fairly representative:

https://policy.umn.edu/research/copyright

TL;DR: It's complicated.

A statement on the UMN mess

amacater — Sat, 24 Apr 2021 16:21:01 +0000

That's pretty much what any commercial organisation would require of its employees to contribute to FLOSS. It doesn't seem too much of a stretch for a university and IRB to do the same: bad reputation redounds on the University.

[This is the same sort of argument that leads organisations to assign mentors: if you're going to submit any old code under
your organisation's name, then you don't want it to be bad code (unless you make the case explicitly that these are students just starting out on coding e.g. as a part of something like a one day introduction to coding for Teach the Nation to Code or whatever.) ]

A statement on the UMN mess

viro — Sat, 24 Apr 2021 14:21:26 +0000

Oh, _lovely_. Let me get it straight - you seem to be suggesting that

1) school should own whatever students might write
2) school should maintain the list of projects students can contribute to and have, for each of those projects, at least one employee familiar with the guts of that project enough to review patches
3) that all patch submissions by the students should be in effect moderated by those employees
4) that any student wishing to contribute must start with checking if the project is on the school's list and petition for its inclusion if it currently isn't, waiting for that request to come through

Are you a genuine article, or is that an illustration of Poe Law?

A statement on the UMN mess

clump — Sat, 24 Apr 2021 13:54:15 +0000

Would it be feasible for an organization, oh let's say UMN, to review their future patches after they've behaved unethically? Certainly.

A statement on the UMN mess

Wol — Sat, 24 Apr 2021 12:28:59 +0000

Much as I hate to agree with you, yes. Punishment for bad faith and deliberate malfeasance NEEDS to be heavy-handed.

The trouble is where do you draw the line between naivety, incompetence, and malfeasance. But as the medical case showed, UMN has a history of cover-ups and lying. I hope UMN *has* been blocked from LKML, and I hope new people with UMN emails *do* find themselves locked out of kernel development.

Tough luck on those people caught up in the scandal, but if the message goes out loud and clear "don't study computing at UMN if you want anything to do with linux" then that's a good message to send.

It's like sports. People get caught out, and don't realise OTC medications carry different substances in different countries. There's been plenty (sadly) of cases where athletes have checked "Medicine X is okay", then they've gone abroad, bought the local one, and it contained banned substances. But any athlete caught deliberately taking banned substances, well, it should be a *lifetime* competition ban, and *all* records stripped. If they want to carry on coaching, competing at a local level, and stuff like that I don't see a problem, but basically they'll have trashed any meaningful career.

It's sad, but the pain of misbehaviour *needs* to be serious. And you need to clamp down *everywhere*. I think the police over here, for example, have shown that "no tolerance" works - by targetting petty crime, major crime goes down too ...

Cheers,
Wol

Experimentation on humans without their consent

ermo — Sat, 24 Apr 2021 11:04:03 +0000

Out of curiousity only, how (if at all) does this standard apply to e.g. government organisations and spy agencies with adversarial (counter-)intent as their raison d'être?

Something like the NSA, GRU, Mossad, BND, MI6 etc.?

The kernel being an international effort, can (and should) the kernel maintainers also be able to ban suspected bad agents from committing on the basis that a subset of their current or past efforts appear to have been made in bad faith and represent a mix of social engineering and technically subversive efforts designed to insert exploitable code?

At this point, Linux is such a critical piece of infrastructure in an international context that it IMHO makes sense to protect it from all subversive tactics, not just the incident in question?

A statement on the UMN mess

MatejLach — Sat, 24 Apr 2021 08:51:13 +0000

Fair, personally I think we're giving this group a little too much benefit of the doubt when at the very least they proved that ethical research is not high on their priority list. To me that basically means that any contributions from them will have to undergo extra scrutiny to *hopefully* determine whether it's a legit patch or some wild joke and I remain unconvinced that this group's good contributions are worth the guessing game and extra stress that their 'research' puts on maintainers.

A statement on the UMN mess

pbonzini — Sat, 24 Apr 2021 08:47:42 +0000

> bulk revert request had, IMO, been wrong. Much too wide (UMN is a big school), wouldn't have caught any sock puppets, dramatically misstated what had been requested

Agreed. But my point is: knowing that this static analyzer from UMN is crap, even if they improve it it will be a while before maintainers start reviewing UMN static analyzer fixes with any interest.

Sending crap patches has happened to everyone, accepting them too. But it's one thing to break some eggs while making an omelette, it's another thing to carelessly drop the entire box of eggs on the floor.

Banning is theatre, loss of trust is not.

A statement on the UMN mess

viro — Sat, 24 Apr 2021 03:00:11 +0000

First of all, I *really* hope umn.edu mail does not get dropped by kernel.org lists; if it is, that should be fixed ASAFuckingP. As for the rest of it... Revert for 0c85a7e87465 ought to have been sent to Linus. By Aditya. As soon as he'd taken a good look at the patch he'd sent - say, on Apr 9, when the first replies started to arrive.

Look, you know and I know that shit happens; so does Linus - we'd all been in situations when embarrassingly bad patch got sent, applied and pushed out. I do not believe that Linus would sit on the author-sent revert request for days - and no such revert had been applied so far.

It doesn't need to be sent (or Cc'd) to any public lists - mail to Linus and davem with anything along the lines of "$commit had been garbage; fortunately it's harmless, but it's completely bogus and should've been caught before sending it out; please revert it" would've taken care of the retraction just fine. _Not_ doing that is really bad form.

Seriously, check that commit. The first chunk: "let's zero a local variable immediately upstream of return, lest we get double-free"; the second one: "we are slightly downstream of spin_unlock_irqrestore(&rm->m_rs_lock, flags); better check that we hadn't somehow gotten through it with rm == NULL" (in the second one rm comes from list_entry(), BTW). It's that bogus...

As for the missing data, I'd been referring to the recent paper on UAF injection and experiment described (FSVO) in there.

A statement on the UMN mess

deater — Sat, 24 Apr 2021 02:07:20 +0000

> If the U of M should have funding pulled from its thousands of researchers over that, then so should many, many major institutions.

yes, I agree with you 100%. We should pull U of Minnesota's funding and then we can get to work on all of the others.

A statement on the UMN mess

bfields — Sat, 24 Apr 2021 02:02:34 +0000

"one of the co-authors of that paper had been recently playing with a static analyzer of theirs and sent a bunch of patches coming out of that. Some of the patches were utter crap. Unfortunately, they got merged. Even more unfortunately, the author *still* have not bothered to send revert request for said garbage patches."

I think umn.edu mail is getting dropped by the kernel lists.

Which doesn't prevent them from responding to you personally. Still, it's not a good way to communicate that we'd like more followup from them.

By the way, https://www-users.cs.umn.edu/~kjlu/papers/crix.pdf does include more data in the appendices. Unfortunately the list is just by filename and line number. Still, knowing that and the authors it'd probably be doable to identify the patches. But that's from a couple years ago, it doesn't cover the latest set of patches.

A statement on the UMN mess

viro — Sat, 24 Apr 2021 01:02:12 +0000

OK, that went far enough. We have several things conflated here.

1) a low-quality paper a while ago, with no data, no experiment protocol, etc. The lack of data is a part of what's blowing the whole thing out of proportion - if they bothered to attach the list (or link to such) of SHA1 of commits that had come out of their experiment, or, better yet, maintained and provided the list of message-ids of all submissions, successful and not, this mess with blanket revert requests, etc. would've been far smaller (if happened at all)

2) one of the co-authors of that paper had been recently playing with a static analyzer of theirs and sent a bunch of patches coming out of that. Some of the patches were utter crap. Unfortunately, they got merged. Even more unfortunately, the author *still* have not bothered to send revert request for said garbage patches. _That_ is the worst (academical) sin he can be charged with in the entire story, AFAICS - if you publish something that turns out to be bogus, you really ought to publish correction or retraction as soon as possible. I am quite certain by now that patches had been crap in good faith; the odds of that being the penetration testing, take 2, are IMO very low.

3) patches claiming to be fixes are sometimes (and I would like to see the dataset behind that paper, exactly because it might provide interesting correlates) taken with only a cursory review. That was another commonality between their paper and the current set of patches, which is what got the mess going.

4) bulk revert request had, IMO, been wrong. Much too wide (UMN is a big school), wouldn't have caught any sock puppets, dramatically misstated what had been requested (it was actually a bulk *review* request put in that form) and got a lot of free publicity for the original paper, while we are at it.

5) results of review so far - nothing dramatic whatsoever. Nothing plausibly malicious, no wrongbots, overall more or less usual quality.

IOW, I don't see any reasons to block UMN folks, including the group involved with that paper.

A statement on the UMN mess

Paf — Sat, 24 Apr 2021 00:33:06 +0000

I want to be clear: I am not trivializing the seriousness of that event. Or other abuses of human beings committed during research. It’s terrible.

But it is not does it represent a pattern associated with the U of M. It’s one horrible incident. If the U of M should have funding pulled from its thousands of researchers over that, then so should many, many major institutions.

A statement on the UMN mess

Paf — Sat, 24 Apr 2021 00:29:53 +0000

*eyes roll so hard in to head it hurts*
No. My alma mater has a few specific incidents over a history stretching back over 150 years, much of that as a *huge* institution (in the 2000s, it was briefly the largest in the US, by student population). There are *so many* incidents of research misconduct spread across academia throughout history, many of them justifiably infamous. The U of M is not known for this, nor should it be.

A statement on the UMN mess

deater — Fri, 23 Apr 2021 23:48:55 +0000

> the university has no particular history of bad conduct outside of this (very serious) incident.

you might look up the "Dan Makingson Case", your alma mater has a long history of unethical research

what should happen here is the NSF should pull all funding from the University. US Government funding is hard to get, over 50% of computer related research grants are denied. If UMN repeatedly shows they can't be trusted to conduct ethical research, then the money should go to Universities than can be trusted. I'm not sure how many chances they should be given.

A statement on the UMN mess

sjj — Fri, 23 Apr 2021 23:34:32 +0000

Yes, the hand wringing about other people with umn.edu addresses now being rejected is misguided. This is obviously a way to get the university's attention and doing it publically forces them to at least investigate. If it proves right, and I have quite a lot confidence in Greg K-H, some people just destroyed their careers. Watch for them try to blame this on some rogue students.

A statement on the UMN mess

Paf — Fri, 23 Apr 2021 22:13:21 +0000

This is my alma mater, and I’ve spent a lot of time lately telling people how incredibly serious their actions were and how incredibly furious I would be if I were Greg.

That said, lot of the conversation here seems a little silly - the university has no particular history of bad conduct outside of this (very serious) incident. The defense of a member of staff or administration (referenced above) who committed significant bad actions is A) unrelated, and B) sadly common and hardly indicative of something especially wrong with *this* university that is not found elsewhere.

This will play out exactly as it is now - the ban is Greg’s best weapon to change things *now*. The two sides will talk about it, the U of M will apologize *profusely*, as they should, they will try to make some changes, they’ll never do anything like this again for many years, and they will be allowed to participate again. (The particular individuals will perhaps not be allowed. Which I’d certainly understand, to say the least.)

This particular IRB may get blown up, but periodic or even systematic bad decisions by IRBs and university officials will continue largely unadjusted.

IRB wasn't consulted until experiment was done

david.a.wheeler — Fri, 23 Apr 2021 21:51:53 +0000

In this case, the IRB was not even *consulted* until the experiment was done. THEN the IRB made a bad after-the-fact decision, though it's hard to tell if its decision was influenced by the fact it was already done.

IRBs are required for any experiment done on humans, at least in the US if they use government funding.

A statement on the UMN mess

david.a.wheeler — Fri, 23 Apr 2021 21:48:31 +0000

> Personally, I think someone from the university ought to sign off on the patches as a representative of the school. if they are being submitted from university email. And if there is misconduct, this person gets the blame.

I think that's excessive & unnecessary.

The issue here is experimentation on humans without their consent. There are already processes to prevent this (namely the university IRB process). Something went wrong, hopefully it can get fixed.

Experimentation on humans without their consent

david.a.wheeler — Fri, 23 Apr 2021 21:44:41 +0000

This was a funded experiment by U of MN researchers on humans (the Linux kernel developers) who had NOT consented to being part of an experiment. The experiment didn't even go through the university's IRB until *after* the experiment was done (NO!), and then the IRB approved an experiment on humans without their consent (NO!). This is a HUGE deal. As GregKH noted, the developers didn't appreciate “being experimented on”.

These were not just "poor patches" either, they *deliberately* created proposals to add vulnerabilities as described in the draft paper, "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits".

I love research! But researchers are not allowed to attack deployed systems without permission from their owners, and researchers are not allowed to experiment on people without consent from those people. These are basic table-stakes for experiments.

A statement on the UMN mess

david.a.wheeler — Fri, 23 Apr 2021 21:32:26 +0000

> Doing this using your personal email or hiding behind a generated email borders on being malevolent and could be characterized as a deliberate fraud, which has many possible legal consequences.

Indeed. Here's a quote straight from the draft paper "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits", Qiushi Wu and Kangjie Lu:

> We submit the three patches using a random Gmail account to the Linux community and seek their feedback—whether the patches look good to them.

A statement on the UMN mess

nedu — Fri, 23 Apr 2021 21:24:27 +0000

In the US, I don't think it's a question of stopping bad code before it reaches "a release or a release candidate."

If the intent of the bad code is an "impairment to the integrity or availability of data, a program, a system, or information", then I think the bad code needs to get stopped before it gets run without authorization on any computer "used in or affecting interstate or foreign commerce or communication, including a computer located outside the United States that is used in a manner that affects interstate or foreign commerce or communication of the United States".

If that's too many words, then what I'm saying is that if the bad code gets run on someone's test machine, then it's some kind of problem.

Now we can ask ourselves how much "real" damage there is to just some test machine, and what the right policy ought to be. And then we can all go write Congress and tell them that some of the bad code they write is quite frankly terrifying for legitimate research...

But do patches get ACK'd without ever being run at all?

A statement on the UMN mess

bfields — Fri, 23 Apr 2021 19:54:49 +0000

it's just they claim those were different research and a result of a 'new static analyzer' whose 'sensitivity is obviously not great'.

I don't think we've seen any strong reason to doubt that at this point.

I mean, it's a research group that's done a lot of different things, so has sent patches as part of various projects at various times, and unsurprisingly a few of them have turned out to have bugs.

This series of reverts from Greg has found a few minor bugs, but it's hard to tell whether the bug rate is really anything unusual: https://lore.kernel.org/lkml/18edc472a95f1d4efe3ef40cc9b8d2611d4ab990.camel@redhat.com/

Ethical board approval for security research

Wol — Fri, 23 Apr 2021 18:59:29 +0000

> I think you're (somewhat violently…strongly?) agreeing with me? I was replying to the implication that 2004 is not recent.

Yup.

Cheers,
Wol

Ethical board approval for security research

mathstuf — Fri, 23 Apr 2021 17:20:00 +0000

I think you're (somewhat violently…strongly?) agreeing with me? I was replying to the implication that 2004 is not recent.

> > 2004 is also short enough time that there's a significant chance that there's overlap in personnel between the two periods

Sounds likely if your assertion is true:

> And the people responsible for the cover-up are still mostly in place.

Ethical board approval for security research

Wol — Fri, 23 Apr 2021 17:15:23 +0000

Read the article. The then-head of the department responsible for SIX suicides? has been given - as the article says - "a soft landing". Sounds like he's no longer *officially* in charge, but still has considerable influence.

And the people responsible for the cover-up are still mostly in place.

Cheers,
Wol

Ethical board approval for security research

lbt — Fri, 23 Apr 2021 17:09:57 +0000

Thanks - I missed that conversation.

A statement on the UMN mess

JoeBuck — Fri, 23 Apr 2021 16:36:05 +0000

There will be those who will attempt to inject malware into the kernel for more malicious purposes than just to get a conference paper out of it, so there might be an argument for doing this kind of testing in a more controlled manner. For example, some companies are testing their employees' ability to recognize phishing, and training them to do a better job at it, by occasionally sending out something that should be recognizable as a phishing attempt.

But deciding on whether to do this or not should be up to Linus and the senior maintainers. They could arrange occasional tests, but have at least two people who are "in the know" who can stop the bad code from reaching a release or a release candidate.

A statement on the UMN mess

MatejLach — Fri, 23 Apr 2021 16:14:21 +0000

Apparently this was not done in all cases. Some of their buggy patches made it into stable, it's just they claim those were different research and a result of a 'new static analyzer' whose 'sensitivity is obviously not great'.

I find this excuse a bit suspect considering it's the same group of people, but even if a few patches were made in good faith, they were in their outcome indistinguishable from the on purpose bad ones.

Not sure I'll miss this group not being able to contribute in particular if am honest.

A statement on the UMN mess

ssmith32 — Fri, 23 Apr 2021 15:54:36 +0000

Also: A fix and bug report was sent immediately after the patches were accepted, and the issues were prevented from making out into the wild.

I don't agree with the research (imagine what would happen if they sent an intern to Google to write vulns as research), but the fact that the kernel side of thing is leaving that out of their reporting seems biased.