Linux-kernen er fyldt 35 år siden den besked, Linus Torvalds sendte til et Usenet-forum den 25. august 1991. Det, der begyndte som en studenterhobby på Helsinki Universitet, træt af MINIX' begrænsninger, er blevet en komponent, der driver 100% af supercomputere , næsten 70% af Android-mobiltelefoner og en betydelig del af internettet og den offentlige sky. Version 7.2 er netop blevet udgivet , og projektets kode overstiger nu 40 millioner linjer, hvoraf omkring 30 millioner er faktisk kode.
Bag den skala ligger en beslutning, der er mere juridisk end teknisk. I de tidlige dage brugte Torvalds sin egen licens, der forbød kommerciel omdistribution og dermed kvalte enhver bæredygtig forretning. I begyndelsen af ​​1992 adopterede han GPLv2 , gældende fra 1. februar, og version 0.95 var den første, der blev udgivet under disse vilkår. Denne formel tillod brug, ændring og omdistribution af koden, forudsat at ændringerne blev udgivet under den samme licens. Dette førte til fødslen af ​​virksomheder som Red Hat og SUSE, og Torvalds selv opsummerede senere, at det at gøre Linux GPL-only var langt det bedste, han nogensinde havde gjort. Kernen forbliver GPL-only: i 2007 nægtede han at migrere til GPLv3 på grund af dens klausul mod tivoisering.
Et projekt, der startede med meget lidt og nĂĄede meget langt
Den første kode, version 0.01, udkom den 17. september 1991 med blot 10.239 linjer og kunne ikke engang køre alene: den krævede MINIX for at kompilere. Version 0.02 ankom den 5. oktober og betragtes som den første "officielle" version, mens version 0.11 i december tog det definitive spring ved at kunne kompilere sig selv, mens den kørte på Linux. Fællesskaberne reagerede hurtigt: i 1993 var der allerede mere end hundrede udviklere, og to distributioner, der stadig eksisterer i dag, Slackware og Debian, blev født.
Ikke alle så det på den måde. Den 29. januar 1992 udgav Andrew Tanenbaum en besked med titlen "Linux er forældet", hvori han argumenterede for, at monolitiske kerner var et design fra 70'erne sammenlignet med mikrokerner, og at et system knyttet til Intel 386 aldrig ville nå andre arkitekturer. Begivenhederne beviste, at Tanenbaum tog fejl på begge punkter: version 1.2, udgivet i marts 1995, tilføjede understøttelse af Alpha, SPARC og MIPS , og siden da er kernen blevet porteret til snesevis af arkitekturer.
Torvalds er træt af trivielle programrettelser skabt med AI
At Linus Torvalds stadig er aktiv, er ikke noget nyt, selvom han selv indrømmer, at han ikke længere bidrager med så mange linjer kode som før. Det, der har ændret sig, er hans utilpashed med den overdrevne brug af kunstig intelligens-værktøjer til at finde og rette fejl. Han er ikke imod AI som et supportværktøj, men han er imod misbrug af det. I kerneversion 7.1 , der i øjeblikket er i sin femte udgave af de sædvanlige syv Release Candidate, har han observeret et overskud af rettelser til ubetydelige fejl, der bruger tid og ressourcer.
Som han forklarede bidragyderne, kommer mange af disse rettelser på upassende tidspunkter. De fleste af rettelserne i RC5 burde have været foreslået i projektets tidlige stadier. Torvalds sagde, at RC5 var ret stor sammenlignet med tidligere versioner på samme stadie, og at han ikke var helt tilfreds med den: det meste bestod af trivielle problemer med almindelige drivere. Hans idé er, at den slags justeringer bør inkluderes i et Linux-next- træ og forenes under mergeperioden, ikke på et senere tidspunkt.
Problemet er ikke kun, at rettelserne er mindre, men at de skaber en flaskehals. Der har været tilfælde, hvor flere personer har fundet og rettet de samme fejl, men rapporteret dem separat. Denne overlapning af rettelser er forvirrende og ineffektiv for de faktiske vedligeholdere. Torvalds har advaret om, at han vil være strengere og begynde at afvise meningsløse pull-anmodninger med mindre rettelser.
Der er også en teknisk risiko. Brug af AI-agenter til at rette en fejl kan utilsigtet skabe en ny, hvilket tilføjer mere arbejde og potentielt endda introducerer en mere alvorlig sårbarhed end den oprindelige. Torvalds opsummerede det med en simpel idé: trivielle rettelser kan være ubetydelige og have en lav sandsynlighed for at forårsage problemer, men "lav sandsynlighed" er ikke det samme som nul sandsynlighed . Hvis nogen ønsker at samarbejde om kernen, er det bedst at undgå at bruge AI til mindre fejl i senere stadier.
Containere er ikke længere et sikkert bur.
Sikkerhedsfirmaet Depthfirst har offentliggjort en analyse, der argumenterer for, at Docker- og Kubernetes-lignende containere ikke længere er en tilstrækkelig robust sikkerhedsbarriere. Deres argument er, at en angriber nemt kan undslippe en container, når de vil. En container giver indtryk af at være sin egen maskine, men den inkluderer ikke et komplet operativsystem: alle containere på en server kører gennem den samme Linux-kerne som værten , der administrerer hukommelse, processor og netværksressourcer.
Mange CTF-arrangører og andre miljøer stoler blindt på og hoster flere tests på den samme server, hver i sin egen container, og er udelukkende afhængige af værtens sikkerhed. Dette skaber en falsk følelse af sikkerhed. Som bevis citerer Depthfirst en AWS-bulletin dateret november 2025, hvor virksomheden ikke længere betragter containere som en sikkerhedsbarriere og derfor ikke bruger dem til at isolere klienter fra hinanden.
Det, der har ændret sig i de seneste måneder, er omkostningerne ved at finde sårbarheder. Med banebrydende AI-modeller kan en angriber med beskedne ressourcer udnytte uopdaterede maskiner, så snart en sårbarhed offentliggøres, hvilket tidligere krævede betydelig ekspertise. Depthfirsts tal illustrerer denne acceleration: 249 CVE'er til Linux-kernen blev offentliggjort i januar og 1.650 i august . Ud af de 36 CVE'er, der blev offentliggjort via Googles kernelCTF, kan 13 udnyttes ved hjælp af almindelige grænseflader, såsom de lokale sockets, som en container modtager som standard.
Den 24. juli sikrede Depthfirst sig en plads på kernelCTF med en zero-day exploit, før nogen patch blev udgivet, og i dag er proof of concept tilgængelig på GitHub. Patchen til Linux-kernen blev udgivet den 6. august, men på Ubuntu angav opdateringen pr. 24. september stadig 26.04-kernen som "Sårbar, igangværende arbejde" og 24.04-kernen som "Sårbar ". Det er blevet hurtigt at finde sårbarheder; det tager tid at rette dem på tværs af alle udgivelser og maskiner.
Hvordan beskytter man sig selv? Depthfirst foreslår at droppe kerneldeling direkte og migrere ikke-tillidfulde arbejdsbelastninger til microVM'er, lette virtuelle maskiner, hvor hver arbejdsbelastning har sin egen kerne. Det er her, projekter som Firecracker og Kata Containers kommer ind i billedet. Hvis en angriber bryder en af ​​disse kerner, kompromitterer de i teorien kun deres egen instans og ikke hele værten. Firecracker er dog afhængig af KVM, virtualiseringskomponenten i værtens Linux-kerne, og KVM har også haft sårbarheder. Januscape tillod undslippe fra den fysiske maskine, hvis værten understøttede indlejret virtualisering. Angrebsfladen er mindre, men ikke ikke-eksisterende. I mellemtiden er det på Ubuntu 24.04 eller 26.04 tilrådeligt at holde øje med ankomsten af ​​den næste kerne; Canonical har annonceret en ugentlig kerneludgivelse for at forsøge at kompensere for dette tempo.
Specter v2 dukker op igen med Branch Target Reuse
VUSec har beskrevet Branch Target Reuse (BTR), et Spectre v2-angreb, der udnyttede cBPF JIT-compileren i Linux til at hente en root-adgangskode-hash. Gruppen rapporterer også, at kerneudviklere har indarbejdet en x86-afhjælpning for at håndtere genbrug af koderegioner. BTR udnytter indirekte branch-forudsigelser, der kan fortsætte, efter at kode genereret af en JIT-compiler er frigivet, og en anden blok genbruger dens adresse. CPU'en kan derefter spekulere i retning af en forældet position i den nye kode.
VUSec beskriver to komplette end-to-end-angreb mod cBPF JIT-compileren på Linux: et med standardkonfigurationen og et andet, der fungerede med konstant obfuscation aktiveret. Demonstrationen gendannede en root-adgangskode-hash fra hukommelsen i en `su`-proces. Det er vigtigt at huske, at en hash ikke er adgangskoden i klartekst: for at få fat i den, skal du forsøge at knække hashen, og chancerne for succes afhænger af algoritmen og adgangskodens styrke. VUSec estimerer lækagen til otte bytes pr. sekund og forklarer, at pointer-tracing reducerer mængden af ​​data, der skal udtrækkes for at nå hemmeligheden.
Processorer forudsiger destinationen for indirekte hop for at udføre instruktioner på forhånd. BTR udnytter det faktum, at denne forudsigelse kan blive forældet sammenlignet med den kode, der i øjeblikket optager en hukommelsesadresse. I Linux-demonstrationen installeres cBPF-programmer som seccomp-filtre. Teknikken fungerede med klassiske BPF-programmer, der er tilgængelige for ikke-privilegerede processer; VUSec adskiller dette fra eBPF, hvis JIT, ifølge gruppen, er begrænset til privilegerede brugere. Resultaterne var ikke de samme på tværs af alle motorer: på Linux cBPF var der to succesfulde exploits; på Firefox SpiderMonkey blev der opnået et proof of concept med forældede forudsigelser efter genbrug af kode, men ikke et fuldt browser-exploit; på Oracle GraalVM mislykkedes et angreb, fordi intern kompilering og garbage collection slettede forudsigelsesposterne. Oracle afbøder genbrug ved at randomisere placeringen af ​​JIT-kodecachen. De rapporterede gennemsnit var tre minutter på Raptor Cove og fem minutter på Lion Cove.
Den kerneintegrerede afhjælpning pålægger en IBPB-barriere, som fjerner den indirekte branch-prædiktor, på alle kerner, når et cBPF-program genbruger en tidligere udført cBPF- eller eBPF-region. Denne foranstaltning modvirker også sådan genbrug. VUSec forbinder identifikatorerne CVE-2026-64507 og CVE-2026-64508 med Linux-problemer og anbefaler at installere operativsystem- og softwareopdateringer, så snart leverandører udgiver programrettelser. Gruppen oplyser, at den observerede adfærden på alle Intel-, AMD- og Arm-CPU'er, den testede, selvom hash-gendannelsesdemonstrationen blev udført på Intel Raptor Cove- og Lion Cove-processorer. Forskningsartiklen om BTR blev accepteret til ACM CCS 2026 og var planlagt til offentliggørelse i november 2026.
Hvad skal man kigge efter, hvis man administrerer Linux-systemer
Selvom jubilæet og udviklingen af ​​kernen er anledning til at fejre, kræver den praktiske side stadig arbejde. I virksomheds- og offentlig administration, især i Spanien og resten af ​​Europa, er det vigtigt ikke at antage, at en container giver tilstrækkelig isolation. Hvis der kører upålidelige arbejdsbelastninger, giver det mere mening at bruge microVM'er med deres egne kerner, gennemgå host-patches og undgå at blande kritiske tjenester på den samme server uden yderligere beskyttelseslag.
Det er også vigtigt at overvåge opdateringscyklussen nøje. Canonicals ugentlige kerneludgivelser hjælper, men de eliminerer ikke behovet for at kontrollere, om en specifik Ubuntu-version stadig er markeret som sårbar. Under udvikling kan AI være nyttig til tunge opgaver, selvom Torvalds har gjort det klart, at han ikke ønsker, at det skal blive en fabrik for mindre patches i kritiske tider. Kernelsikkerhed afhænger af at gennemgå, prioritere og patche med omhu, ikke af at akkumulere ændringer blot fordi et værktøj nemt kan generere dem.
Linux-kernen når sit 35-års jubilæum med enorm skala, over 40 millioner linjer kode og en tilstedeværelse i supercomputere, mobile enheder og skyen. Samtidig står den over for intern debat om brugen af ​​AI i udvikling, angreb som BTR, der udnytter hardware, og et fundamentalt problem med containere: de deler kernen og er ikke længere tilstrækkelige som eneste forsvar. Historien om fri software er fortsat stærk, men at vedligeholde den kræver rettidige programrettelser, stærkere isolering og fornuftige tekniske beslutninger uden genveje.
