Yes, and you think it follows from that that I believe that it's hard to introduce a malicious patch?
It neither follows, nor is my belief.
Conversation
OK, yes, that was what I thought and it certainly seemed to be what you were indicating.
2
But it sounds like we're on the same page now - it's trivial for anyone to submit bugdoors to the kernel.
1
1
I think it's non-trivial, but I'm happy to concede it's easier than it should be.
1
But again, I don't think that's useful or actionable information.
A better "result" would be recognizing that the C language is a large source of issues and figuring out ways to help the kernel migrate away from it.
There are people working in better faith on those slns.
2
Look through lkml.org/lkml/2021/4/14. Peter Zijlstra is one of the most important core kernel maintainers.
The Linux kernel also has a lot more issues than the unsafety of C. The monolithic kernel architecture is as much of an issue, among other serious problems with it.
1
2
Rust is perfectly suitable for writing Linux kernel code. The biggest barrier is not building the infrastructure for it. It's convincing them to accept it and start using it at all. It doesn't need language changes for it. Problems raised there already have available solutions.
1
Similarly, they could choose to start using isolated code. The infrastructure for that was already partially built already. Good luck convincing them to accept even tiny performance and code size costs for it though, or even that it's a safer and more reliable architecture...
1
Some of the most important kernel maintainers will happily argue that C is the safest language to use and a monolithic kernel design is safer because it doesn't have the complexity of isolation and messaging passing. I'm not presenting strawman arguments. They say that stuff.
1
3
They often argue against optional attack surface reduction, useful mitigations, etc. and come up with ways to deride work on improving reliability and security.
Peter rejected support for letting non-root users using perf events, despite it being adopted by Android, Debian, etc.
He's often there deriding that kind of work, and is often in a position where he can reject it himself or sabotage it. That's what people are dealing with. He's hardly the only example. Linus himself often does the same stuff, but at least he acknowledges a lot of the problems.
1
1
I clearly remember Linus ridiculing the concept of having convenience functions for doing correct overflow checks and many other examples.
Not a project where you can contribute to correctness/security unless you enjoy dealing with tons of politics and non-merit-based decisions.
1
Show replies