Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?
> non-existent... static analysis .... Whats being done to address those issues?
Static analysis is being done[1][2], in addition, there are also CI test farms[3][4], fuzzing farms[5], etc. Linux is a project that enough large companies have a stake in that there are some willing to throw resources like this at it.
Human review is supposed to be done through the mailing list submission process. How well this works depends in my experience from ML to ML.
Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!
This patch wasn't. Other patches from the university had made it into stable and are likely to be reversed, not because of known problems with the patches, but because of the ban.
this is a dangerous understanding of Rust. Rust helps to avoid certain kinds of bugs in certain situations. Bugs are very much possible in Rust and the scope of bugs usually depends more on the system than the language used to write it.
I get where you're coming from, but I disagree. They actually prey on seemingly small changes that have large "unintended"/non-obvious side-effects. I argue that finding such situations is much much harder in Rust than in C. Is it impossible? Probably not (especially not in unsafe code), but I do believe it limits the attack surface quite a lot. Rust is not a definitive solution, but it can be a (big) part of the solution.
yes it definitely limits the attack surface. remember that in systems programming there are bugs that cause errors in computation, which Rust is pretty good at protecting; but there are also bugs which cause unintended behaviors, usually from incorrect or incomplete requirements, or implementation edge cases.
