De Linux-kernel is 35 jaar oud sinds dat bericht dat Linus Torvalds op 25 augustus 1991 naar een Usenet-forum stuurde. Wat begon als een hobbyproject van een student aan de Universiteit van Helsinki, die de beperkingen van MINIX beu was, is uitgegroeid tot een component dat 100% van de supercomputers , bijna 70% van de Android-telefoons en een aanzienlijk deel van het internet en de publieke cloud aandrijft. Versie 7.2 is zojuist uitgebracht en de code van het project telt nu meer dan 40 miljoen regels, waarvan ongeveer 30 miljoen daadwerkelijke code is.
Achter die omvang schuilt een beslissing die meer juridisch dan technisch van aard is. In de beginjaren gebruikte Torvalds zijn eigen licentie die commerciële herdistributie verbood, waardoor elke duurzame bedrijfsactiviteit werd belemmerd. Begin 1992 nam hij de GPLv2 aan , die op 1 februari inging, en versie 0.95 was de eerste die onder die voorwaarden werd uitgebracht. Deze formule stond het gebruik, de aanpassing en de herdistributie van de code toe, op voorwaarde dat de aanpassingen onder dezelfde licentie werden gepubliceerd. Dit leidde tot de oprichting van bedrijven als Red Hat en SUSE, en Torvalds zelf concludeerde later dat het GPL-only maken van Linux verreweg het beste was wat hij ooit had gedaan. De kernel blijft GPL-2.0-only: in 2007 weigerde hij over te stappen naar GPLv3 vanwege de clausule tegen tivoïsering.
Een project dat met weinig begon en heel ver is gekomen.
De eerste versie van de code, 0.01, verscheen op 17 september 1991. Deze bestond uit slechts 10.239 regels code en kon niet eens zelfstandig draaien: MINIX was nodig om de code te compileren. Versie 0.02 verscheen op 5 oktober en wordt beschouwd als de eerste "officiële" versie. In december maakte versie 0.11 de definitieve sprong voorwaarts door zichzelf te kunnen compileren en draaien op Linux. De community reageerde snel: in 1993 waren er al meer dan honderd ontwikkelaars en werden twee distributies geboren die vandaag de dag nog steeds bestaan: Slackware en Debian.
Niet iedereen zag het zo. Op 29 januari 1992 publiceerde Andrew Tanenbaum een ​​bericht met de titel "Linux is verouderd", waarin hij betoogde dat monolithische kernels een ontwerp uit de jaren 70 waren in vergelijking met microkernels en dat een systeem dat gebonden was aan de Intel 386 nooit andere architecturen zou bereiken. De gebeurtenissen bewezen dat Tanenbaum op beide punten ongelijk had: versie 1.2, uitgebracht in maart 1995, voegde ondersteuning toe voor Alpha, SPARC en MIPS , en sindsdien is de kernel geporteerd naar tientallen architecturen.
Torvalds is de triviale patches die door AI worden gemaakt beu.
Dat Linus Torvalds nog steeds actief is, is niets nieuws, hoewel hij zelf toegeeft dat hij niet meer zoveel regels code bijdraagt ​​als voorheen. Wat wel veranderd is, is zijn ongemak met het overmatige gebruik van kunstmatige intelligentie om bugs op te sporen en te verhelpen. Hij is niet tegen AI als ondersteunend hulpmiddel, maar wel tegen misbruik ervan. In kernelversie 7.1 , momenteel de vijfde Release Candidate van de gebruikelijke zeven, heeft hij een overdaad aan fixes voor onbeduidende bugs geconstateerd, die tijd en middelen verspillen.
Zoals hij aan de bijdragers uitlegde, komen veel van deze oplossingen op een ongepast moment. De meeste oplossingen in RC5 hadden in een eerder stadium van het project voorgesteld moeten worden. Torvalds zei dat RC5 vrij omvangrijk was in vergelijking met eerdere versies in hetzelfde stadium en dat hij er niet helemaal tevreden mee was: het betrof voornamelijk triviale problemen met veelgebruikte drivers. Zijn idee is dat dit soort aanpassingen in een Linux-next- tree opgenomen en tijdens de merge-periode samengevoegd zouden moeten worden, en niet in een later stadium.
Het probleem is niet alleen dat de patches klein zijn, maar ook dat ze een knelpunt vormen. Er zijn gevallen bekend waarbij meerdere mensen dezelfde bugs vonden en verhielpen, maar deze afzonderlijk rapporteerden. Deze overlapping van patches is verwarrend en inefficiënt voor de daadwerkelijke beheerders. Torvalds heeft gewaarschuwd dat hij strenger zal optreden en zinloze pull requests met kleine fixes zal gaan afwijzen.
Er is ook een technisch risico. Het gebruik van AI-agenten om een ​​bug te verhelpen kan onbedoeld een nieuwe bug creëren, wat extra werk met zich meebrengt en mogelijk zelfs een ernstiger kwetsbaarheid introduceert dan de oorspronkelijke. Torvalds vatte het als volgt samen: triviale fixes zijn misschien onbeduidend en hebben een lage kans om problemen te veroorzaken, maar "lage kans" is niet hetzelfde als nul kans . Als iemand wil meewerken aan de kernel, is het het beste om AI voor kleine bugs in latere ontwikkelingsfasen te vermijden.
Containers zijn niet langer een veilige kooi.
Het beveiligingsbedrijf Depthfirst heeft een analyse gepubliceerd waarin wordt betoogd dat containers in de stijl van Docker en Kubernetes niet langer een voldoende robuuste beveiligingsbarrière vormen. Volgens hen kan een aanvaller gemakkelijk ontsnappen uit een container wanneer hij maar wil. Een container wekt de indruk een eigen machine te zijn, maar bevat geen volledig besturingssysteem: alle containers op een server draaien via dezelfde Linux-kernel als de host , die het geheugen, de processor en de netwerkbronnen beheert.
Veel CTF-organisatoren en andere omgevingen vertrouwen blindelings op de beveiliging van de host en hosten meerdere tests op dezelfde server, elk in een eigen container. Dit creëert een vals gevoel van veiligheid. Als bewijs hiervoor haalt Depthfirst een AWS-bulletin aan uit november 2025, waarin het bedrijf containers niet langer als een beveiligingsbarrière beschouwt en ze daarom niet gebruikt om clients van elkaar te isoleren.
Wat de afgelopen maanden is veranderd, is de drempel om kwetsbaarheden te vinden. Dankzij geavanceerde AI-modellen kan een aanvaller met beperkte middelen een exploit creëren tegen onbeveiligde machines zodra een kwetsbaarheid wordt gepubliceerd, iets waarvoor voorheen aanzienlijke expertise nodig was. De cijfers van Depthfirst illustreren deze versnelling: in januari werden 249 CVE's voor de Linux-kernel gepubliceerd en in augustus 1.650. Van de 36 CVE's die via Google's kernelCTF zijn bekendgemaakt, kunnen er 13 worden misbruikt met behulp van gewone interfaces, zoals de lokale sockets die een container standaard ontvangt.
Op 24 juli wist Depthfirst een plek te bemachtigen op de kernelCTF met een zero-day exploit, nog voordat er een patch was uitgebracht, en vandaag is het proof of concept beschikbaar op GitHub. De patch voor de Linux-kernel werd uitgebracht op 6 augustus, maar op Ubuntu stond de 26.04-kernel in de update van 24 september nog steeds vermeld als "Kwetsbaar, werk in uitvoering" en de 24.04-kernel als "Kwetsbaar ". Het vinden van kwetsbaarheden gaat snel; het oplossen ervan in alle releases en op alle machines kost tijd.
Hoe kunt u uzelf beschermen? Depthfirst stelt voor om kernel sharing direct te laten vallen en onbetrouwbare workloads te migreren naar microVM's, lichtgewicht virtuele machines waarbij elke workload zijn eigen kernel heeft. Projecten zoals Firecracker en Kata Containers bieden hiervoor een oplossing. Als een aanvaller een van deze kernels kraakt, compromitteert hij in theorie alleen zijn eigen instantie en niet de hele host. Firecracker is echter afhankelijk van KVM, de virtualisatiecomponent van de Linux-kernel, en KVM kent ook kwetsbaarheden. Januscape maakte ontsnapping van de fysieke machine mogelijk als de host geneste virtualisatie ondersteunde. Het aanvalsoppervlak is kleiner, maar niet nihil. Ondertussen is het op Ubuntu 24.04 of 26.04 raadzaam om de komst van de volgende kernel in de gaten te houden; Canonical heeft een wekelijkse kernelrelease aangekondigd om dit tempo te compenseren.
Specter v2 is terug met Branch Target Reuse.
VUSec heeft Branch Target Reuse (BTR) beschreven, een Spectre v2-aanval die de cBPF JIT-compiler in Linux misbruikte om een ​​hash van een rootwachtwoord te achterhalen. De groep meldt ook dat kernelontwikkelaars een x86-mitigatie hebben geïmplementeerd om hergebruik van codegebieden aan te pakken. BTR maakt gebruik van indirecte vertakkingsvoorspellingen die kunnen blijven bestaan ​​nadat code die door een JIT-compiler is gegenereerd, is vrijgegeven en een ander blok zijn adres hergebruikt. De CPU kan dan speculeren naar een verouderde positie binnen de nieuwe code.
VUSec beschrijft twee complete end-to-end exploits tegen de cBPF JIT-compiler op Linux: één met de standaardconfiguratie en een andere die werkte met constante obfuscatie ingeschakeld. De demonstratie herstelde een root-wachtwoordhash uit het geheugen van een `su`-proces. Het is belangrijk om te onthouden dat een hash niet het wachtwoord in platte tekst is: om het te verkrijgen, moet je proberen de hash te kraken, en de kans op succes hangt af van het algoritme en de sterkte van het wachtwoord. VUSec schat het lek op acht bytes per seconde en legt uit dat pointer tracing de hoeveelheid data vermindert die moet worden geëxtraheerd om het geheim te bereiken.
Processors voorspellen de bestemming van indirecte sprongen om instructies uit te voeren. BTR maakt gebruik van het feit dat deze voorspelling verouderd kan raken ten opzichte van de code die momenteel een geheugenadres bezet. In de Linux-demonstratie werden cBPF-programma's geïnstalleerd als seccomp-filters. De techniek werkte met klassieke BPF-programma's die beschikbaar waren voor processen zonder privileges; VUSec onderscheidt dit van eBPF, waarvan de JIT, volgens de groep, beperkt is tot gebruikers met privileges. De resultaten waren niet hetzelfde voor alle engines: op Linux cBPF waren er twee succesvolle exploits; op Firefox SpiderMonkey werd een proof of concept verkregen met verouderde voorspellingen na hergebruik van code, maar geen volledige browser-exploit; op Oracle GraalVM mislukte een aanval omdat interne compilatie en garbage collection de voorspellingen verwijderden. Oracle beperkt hergebruik door de locaties van de JIT-codecache te randomiseren. De gerapporteerde gemiddelden waren drie minuten op Raptor Cove en vijf minuten op Lion Cove.
De in de kernel geïntegreerde beveiligingsmaatregel legt een IBPB-barrière op, die de indirecte branch predictor wist, op alle kernels wanneer een cBPF-programma een eerder uitgevoerde cBPF- of eBPF-regio hergebruikt. Deze maatregel ontmoedigt dergelijk hergebruik. VUSec koppelt de identificaties CVE-2026-64507 en CVE-2026-64508 aan Linux-problemen en adviseert om besturingssysteem- en software-updates te installeren zodra leveranciers patches uitbrengen. De groep stelt dat het gedrag is waargenomen op alle geteste Intel-, AMD- en Arm-CPU's, hoewel de demonstratie van hashherstel werd uitgevoerd op Intel Raptor Cove- en Lion Cove-processors. Het onderzoeksartikel over BTR is geaccepteerd voor ACM CCS 2026 en de publicatie staat gepland voor november 2026.
Waar moet je op letten als je Linux-systemen beheert?
Hoewel het jubileum en de evolutie van de kernel reden tot feest zijn, is er in de praktijk nog werk aan de winkel. In bedrijfs- en overheidsomgevingen, met name in Spanje en de rest van Europa, is het belangrijk om er niet zomaar vanuit te gaan dat een container voldoende isolatie biedt. Als er onbetrouwbare workloads draaien, is het verstandiger om microVM's met hun eigen kernels te gebruiken, de patches van de host te controleren en te voorkomen dat kritieke services op dezelfde server draaien zonder extra beveiligingslagen.
Het is ook belangrijk om de updatecyclus nauwlettend in de gaten te houden. De wekelijkse kernelreleases van Canonical zijn nuttig, maar ze nemen niet de noodzaak weg om te controleren of een specifieke Ubuntu-versie nog steeds als kwetsbaar is gemarkeerd. Tijdens de ontwikkeling kan AI nuttig zijn voor zware taken, hoewel Torvalds duidelijk heeft gemaakt dat hij niet wil dat het een fabriek wordt voor kleine patches tijdens kritieke momenten. Kernelbeveiliging is afhankelijk van het zorgvuldig beoordelen, prioriteren en patchen , niet van het simpelweg verzamelen van wijzigingen omdat een tool ze gemakkelijk kan genereren.
De Linux-kernel viert zijn 35e verjaardag met een enorme omvang, meer dan 40 miljoen regels code, en een aanwezigheid in supercomputers, mobiele apparaten en de cloud. Tegelijkertijd wordt er intern gedebatteerd over het gebruik van AI in de ontwikkeling, aanvallen zoals BTR die hardware misbruiken, en een fundamenteel probleem met containers: ze delen de kernel en zijn niet langer voldoende als enige verdediging. De geschiedenis van vrije software blijft sterk, maar het in stand houden ervan vereist tijdige patches, betere isolatie en degelijke technische beslissingen zonder compromissen.
