University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

[MadCatX]

How is that related to the subject? Responsible disclosure is when you find a bug.

No. Responsible disclosure applies whenever you find a security vulnerability. Bugs in code are only one form of it. Insufficient code review procedures - which is what is discussed in their paper - is also a security vulnerability.

No that's not really why things happen but anyway...

Would you care to elaborate what you mean by this sentence?

[oiaohm]

Did anybody even bother to read a little deeper or everyone is just jumping on the 'bad bad bad' hype?

A number of reviewers are recommending leaving some of the commits untouched because they introduced no issues, or otherwise ended up fixing issues for real.

If a bunch of 'malicious' commits made by a professor and a bunch of undergrad students fixes problems in the kernel, it's blatant proof of how fragile and messed up the kernel has become.

That idea of profressor doing malicious commits then having undergrad students fix them is not a legal method most countries. Its criminal under sabotage or treason depending on the country. Treason you can end up dead for it.

To-do the research they were wanting to-do to be legal you need approval of the maintainers to make sure that the intentionally flawed code you were adding would never make it to production branches. Of course getting approval on the Linux kernel is not going to happen. It may have been possible with Libreoffice for testing out the automated quality control. It would have require some serous effort to find an accepting project and have valid side gains to the experiment.

There is a problem here the fact they have been doing malicious commits leaving the commits untouched is really not a option. Introduced no issuses is very hard to prove think something that makes kernel weaker to rowhammer or equal hardware faults on a code level may look totally harmless. Same with fixing issues does properly fix those faults or was just something the fixed by mistake while adding another fault.

Please note this is not the first time a person or a organisation full lot of commits have been removed from the Linux kernel due to these kinds of bad behaviours either. Its the first time a University has been stupid enough to allow this and get caught.

[Sonadow]

That idea of profressor doing malicious commits then having undergrad students fix them is not a legal method most countries. Its criminal under sabotage or treason depending on the country. Treason you can end up dead for it.

You are already misunderstanding me. I said that the professor and his undergrads introduced malicious commits into the kernel and yet some of the kernel reviewers found that a few of these malicious commits had the unexpected effect of actually solving real bugs. How messed up can the kernel be that malicious commits end up fixing issues?

Whether or not they are doing something illegal is not the point I am trying to make, and I am completely not interested in the topic. That's for the university's board and the courts to decide.

[fitzie]

This wasn't a violation of the CODE OF CONDUCT. This is sad unfortunate behavior by one of the senior maintainers when these students aren't even accused of one violation of the CODE OF CONDUCT. What is the point of a CODE OF CONDUCT when you can follow it's rules "to the T" and still get banned?

[User42]

Would you care to elaborate what you mean by this sentence?

This is not about banning people because those commits were potentially harmful. I hope it is clear if that was the reason, everybody would be banned: introducing new bugs is a very common thing after all. If you look at the series of emails, Greg most likely did not like being treated as a lab rat (understandable) especially without anybody in the kernel being involved (very understandable). Though a certain amount of secrecy is necessary not to bias the study, not involving anyone is a bad idea.

Now there is a new series of patches that he perceived as useless, not harmful, useless. It looks like his conclusion was that they are being used as lab rats again, therefore ban. Now, as Sonadow noted, some reviewer actually think some of these patches are good, fix problems and are probably not malicious. Considering the content of the paper, this might be (I insist, might be) the result of the application of the workflow they recommended or it might be a new experiment. Anyway he was not afraid of harmful commits, he clearly does not want the kernel to become an Academic playground.

[geearf]

you could still opt for a bigger [than Minix] open-source project that isn't mission-critical, such as Blender or LibreOffice. You're not compromising a business' integrity by meddling with those, and they're easy to downgrade if necessary.

If their point was to verify the safety of the Linux kernel, one of the biggest, if not the biggest, FOSS project, they could not do it with a different one.
I think what they tried to achieve may have been very fine, but they should definitely had asked permission from Linus or Greg first, and let them know to not get these patches in. Had they done that ethically, there would have nothing too wrong about picking such a critical project.

[User42]

You are already misunderstanding me. I said that the professor and his undergrads introduced malicious commits into the kernel and yet some of the kernel reviewers found that a few of these malicious commits had the unexpected effect of actually solving real bugs. How messed up can the kernel be that malicious commits end up fixing issues?

That's actually one of the points of the paper: you solve a problem, potentially another bug, but as you do you also introduce a stealthy bug, something that is hard to track or identify. If you remove the bug (e.g. use after free or uninitialised variable), the fix should still be mostly good. From what I gathered, they did what could be qualified as "sloppy contributions" on purpose, like dozens are done every cycle. It's just that in their case they know they introduced bugs whereas those other normal "sloppy" contributors don't know it.

[oiaohm]

You are already misunderstanding me. I said that the professor and his undergrads introduced malicious commits into the kernel and yet some of the kernel reviewers found that a few of these malicious commits had the unexpected effect of actually solving real bugs. How messed up can the kernel be that malicious commits end up fixing issues?

All kernel developers will admit over time they get more skilled. No operation alteration commits in most likely would have also resulted in solving some real bugs.

I remember the one Linux kernel plumbers conference presentation where one developer admit straight up that in one case with a major fault when he did git blame he was the one that wrote it over a decade before. Back then at his skill level the code looked sane and valid but today to him the same code looks like it was written by a idiot.

Remember finding some faults in code is not simple. Yes malicious commit may have altered code that made where the real fault was displayed. But its still a malicious commit.

https://en.wikipedia.org/wiki/Fault_injection

There is a development process called Fault injection and another option.

https://en.wikipedia.org/wiki/Mutation_testing

Yes mutation testing is do small modifications that technically break the program. I believe the university could have been experimenting with Mutation testing
Equivalent mutants detection is one of biggest obstacles for practical usage of mutation testing. The effort needed to check if mutants are equivalent or not can be very high even for small programs.
That the problem. Yes we know mutation testing can make particular faults in code more visible but this was also know in 1997 that this was a high risk there was a paper in 2014 that could address some of the issue but not all. Remember if your mutation is not equivalent you have introduced a fault.

Also Sonadow how many extra line of code that doing mutation testing will cause to be reviewed that are faultless and make the process of bisecting of faults slower. Basically we don't know how many fault would have not been discovered by the wasted time working on pointless patches.

Do notice something here yes they claim they were messing around with a new analyzation tool but then releasing white papers saying this is why open source is insecure.

Sonadow fault injection and mutation testing ideas both appear at the same time. We use fault injection commonly with fuzz testing and so on these methods are predictable and will not add faults that were not their before. Mutation testing we don't have the knowledge to-do it safely without risking adding security faults. Mutation testing if performed has to be keep off mainline/production code until someone can work out how to do it safely.

[schmidtbag]

If their point was to verify the safety of the Linux kernel, one of the biggest, if not the biggest, FOSS project, they could not do it with a different one.
I think what they tried to achieve may have been very fine, but they should definitely had asked permission from Linus or Greg first, and let them know to not get these patches in. Had they done that ethically, there would have nothing too wrong about picking such a critical project.

But the article wasn't Linux-specific. The gist of the article applies to many projects, Linux is just the largest one.

[finalzone]