I am not defending the academics but I don't rely on them to keep everything around me running and secure.
The maintainers' reaction is not rude, is concerning! It sounds like they rely on checking the evil bit to stop malicious patches.
What if HackingTeam has Gmail addresses?
Conversation
Replying to
My read is that they're annoyed about having their time wasted intentionally, not that they are blocking the domain as a security precaution, but I might be misunderstanding
4
23
The researchers were submitting correct patches too. They say that in 3 cases, they submitted intentionally incorrect patches and then told the maintainers it was wrong and provided the correct patch instead.
They were seemingly doing useful work on the kernel for the most part.
1
2
Lots of these patches appear to be correct fixes for memory corruption, etc. and are going to be reverted due to loss of trust in the authors. In reply to Greg's post on Twitter, a kernel maintainer states a patch to the code they maintain was correct but it's being reverted.
2
1
My impression is that the kernel maintainers are angry they were embarrassed this way and are reverting all of the useful work that was done out of spite.
I don't think this study was fully ethical but I don't think they were being malicious and appeared to be trying to help.
3
1
I don't think it's malicious. But the intransparency of the researchers along with the responses makes it a great deal worse. We still don't know which patches where part of the research, and that is a problem.
1
The research was unethical, but the problem goes far beyond that. Are they going to revert and review other similar patches which were not meaningfully understood, tested or reviewed? No, just these ones.
The process for accepting code does not counter bad actors well at all.
1
I don't think I agree with the revert, but I don't think you need this research to hilight the review problem with a project such as Linux either.
It just seems like cheap research to me.
1
I think it is needed as long as key people downplay the problems and try to make it seem like the status quo is fine.
Linux kernel code has very low quality and complexity far beyond a level that can be managed with the tools and processes that are being used, and they deny it.
2
I haven't gotten the impression people are downplaying it. I have seen Greg raise the lack of review as a major problem on several occasions?
The largest disappointment is how the research was conducted and presented in the end :/
1
1
The greatest disappointing to me is that I use software where random malicious people can submit patches that will be merged without any real attempt to understand the code and determine if it is correct or not.
I don't think Greg is part of that problem. He's very open and honest about the problems with the kernel. He's also very welcoming to people trying to improve it. I'm not talking about him.
Peter Zijlstra is an egregious example. Linus often qualifies too, as do many others.
1
1
I read through all of lkml.org/lkml/2021/4/14 today. I have a lot of sympathy towards both Greg KH and what the grsecurity folks say about the kernel maintainers / processes.
2
Show replies