Google slams Linux kernel, says it needs major security investment

Downstream vendors should allocate more resources to the upstream kernel, suggests Google

Google has highlighted what it says are shortcomings in the Linux kernel from a security perspective, and the issues these create for downstream vendors who roll the kernel into products.

In a blog post, Kees Cook from Google’s Open Source Security Team compares the Linux kernel to the US automotive industry of the 1960s in order to drive home the point that while the kernel runs flawlessly, when it fails, it falls apart miserably.

“The huge community surrounding Linux allows it to do amazing things and run smoothly. What's still missing, though, is sufficient focus to make sure that Linux fails well too,” wrote Cook.

Cook states he believes the problem is two-pronged. First, Linux needs to invest to make sure its code is robust, which will ensure that bugs don’t manifest at the rate that they do currently. But when they do, they should also be handled in a more efficient manner than the current arrangement.

Calling all downstream vendors

Sharing the “sobering” statistics, Cook says that the stable bug-fix only release of the kernel comes out with about 100 new fixes every week. This leaves downstream vendors with three choices; either to ignore all fixes, prioritize the “important” ones, or apply them all.

Highlighting the issues with all three strategies, he says that the only real option, from a security point of view, is to apply all fixes. This option however presents an engineering nightmare for vendors.

Instead Cook suggests that rather than individual vendors applying the fixes, greater onus should be laid on increasing upstream collaboration. He suggests various mechanisms including introducing more automated testing, continuous integration, and other steps to streamline the kernel’s development process.

“Instead of testing kernels after they're released, it's more effective to test during development,” suggests Cook, asking downstream vendors to infuse at least a 100 more engineers to work on the upstream kernel.

Source