Linux-kernel rammelt onverantwoord, volgens Google

In een blog van het open security team van Google, vraagt Kees Cook - die bij Google veel tijd besteedt aan de veiligheidsproblematiek van de Linux-kernel - om een betere organisatie binnen de gemeenschap die werkt aan de Linux-kernel. Cook zet op een rij hoeveel bugfixes de afgelopen 3,5 jaar aan het licht kwamen.

Gemiddeld kwamen er per week net iets minder dan 100 fixes beschikbaar voor ontdekte problemen. Voor organisaties die de Linux-kernel gebruiken als basis is continue upgraden naar de laatste versie de enige manier om te zorgen dat er geen misbruik kan worden gemaakt van hun producten en diensten. Maar dat is een ondoenlijke en riskante zaak. Het is immers altijd de vraag wat een bugfix doet met de stabiliteit en de functionaliteit van de software die om de kernel heen is gebouwd.

Alleen de belangrijke fixes meteen uitvoeren, is volgens Cook ook geen optie omdat het veel werk is o uit te zoeken welke dat zijn. Veel van de problemen hebben namelijk geen CVE (Common Vulnerabilities and Exposures)-notering of die komt veel te laat. Daardoor kan niet snel worden beoordeeld wat de impact van een geconstateerd probleem is, zoals dat bij veel commerciële software het geval is.

Een ander probleem is dat bij veel producenten oudere versies van de Linux-kernel in gebruik zijn. Die organisaties moeten uitzoeken of geconstateerde problemen ook in die betreffende versie voorkomen en, als reparatie belangrijk is, de fix geschikt maken voor de betreffende versie. Dat betekent dat veel dubbel werk gedaan wordt.

De oplossingen liggen voor de hand

Cook heeft een aantal voorstellen die zouden kunnen leiden tot een oplossing van het probleem. Zo suggereert hij dat de gemeenschap afstapt van de nu gebruikelijke workflow op basis van e-mail. Bovendien zou de gemeenschap baat kunnen hebben bij de inzet van veel meer geautomatiseerd testen en methodieken voor continous integration. Op dit moment vindt veel van het testwerk pas achteraf plaats, vaak pas nadat een versie is vrijgegeven. Het hele proces kan volgens Cook veel efficiënter.

Hij toont zich verder voorstander van het overschakelen op Rust als vervanger van C als programmeertaal. Daarmee kunnen veel geheugenfouten gelijk worden ondervangen.

Tenslotte constateert hij dat veel van de bedrijven die de Linux-kernel nu verwerken heel veel tijd en moeite steken in het fixen van de kernelversies. Als ze de mensen die daarmee bezig zijn 'upstream' zouden inzetten, dus toevoegen aan de Linux-kernelgemeenschap, kunnen ze hun tijd besteden aan het voorkomen van problemen in plaats van ze achteraf te repareren. Bovendien zouden de webgiganten als Google, Amazon en Facebook - die miljarden verdienen aan diensten gebaseerd op de Linux-kernel - best 100 extra ontwikkelaars in dienst kunnen nemen en die laten werken voor het Linux-kernelproject.