Development

Security
Kees Cook

Linux-kernel rammelt onverantwoord, volgens Google

100 bugfixes per week is echt te veel.

Kees Cook © CC BY 2.0 - creativecommons.org hupstream
4 augustus 2021

100 bugfixes per week is echt te veel.

Google haalt flink uit naar de community achter de ontwikkeling van de Linux-kernel. De niet-aflatende stroom patches zorgt voor een onwerkbare situatie voor alle organisaties bij wie de Linux-kernel de basis vormt voor producten en diensten.

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.

Lees meer over Development OP AG Intelligence
1
Reacties
van Zanten 05 augustus 2021 13:22

Een deel van de problematiek komt doordat er nog nauwelijks 'old school' C-programmeurs zijn die tot op systeemniveau snappen wat hun code precies doet met de CPU, devices en het geheugen. En ook nog gewoon de klassieke deskcheck doen en niet trial en error met de compiler tot de fouten eruit zijn en de warnings gemaskeerd.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.