Over on the Google Security Blog, Kees Cook describes his vision for approaches to assuring kernel security in a more collaborative way. He sees a number of areas where companies could work together to make it easier for everyone to use recent kernels rather than redundantly backporting fixes to older kernel versions. It will take more engineers working on things like testing and its infrastructure, security tool development, toolchain improvements for security, and boosting the number of kernel maintainers:
Long-term Linux robustness depends on developers, but especially on effective kernel maintainers. Although there is effort in the industry to train new developers, this has been traditionally justified only by the “feature driven” jobs they can get. But focusing only on product timelines ultimately leads Linux into the Tragedy of the Commons. Expanding the number of maintainers can avoid it. Luckily the “pipeline” for new maintainers is straightforward.
Maintainers are built not only from their depth of knowledge of a subsystem’s technology, but also from their experience with mentorship of other developers and code review. Training new reviewers must become the norm, motivated by making upstream review part of the job. Today’s reviewers become tomorrow’s maintainers. If each major kernel subsystem gained four more dedicated maintainers, we could double productivity.