Google brengt Linux dichter bij kernelupdates zonder server opnieuw te moeten starten

Linux ondersteunt al jaren het toepassen van bepaalde beveiligingspatches op de kernel zonder dat de machine hoeft te worden uitgeschakeld. Echter, het volledig vervangen van de volledige kernel door een andere versie, terwijl processen zoals virtuele machines, databases of in-memory services blijven draaien, is een veel complexere uitdaging. Twee technologieën, ontwikkeld in grote mate rondom de behoeften van Google, Kexec HandOver (KHO) en Live Update Orchestrator (LUO), brengen deze mogelijkheid dichter bij een standaardkernel en zouden de manier waarop high-availability Linux-infrastructuren worden beheerd ingrijpend kunnen veranderen.

De kernpunten van KHO en LUO in 20 seconden

• KHO werd geïntroduceerd in Linux 6.16 en maakt het mogelijk om geheugenregio’s tijdens een overgang te behouden met behulp van kexec.
• LUO werd later geïntroduceerd in Linux 6.19 en organiseert het behoud en herstel van resources tussen beide kernels.
• De belangrijkste toepassing is in cloud-hypervisors waarbij het opnieuw opstarten van de host invloed zou hebben op virtuele machines.
• systemd 261 integreert LUO om bestandsdescriptors van services te behouden.
• Het blijft nog steeds ontwikkelingsfase: kernelwisselingen zonder conventioneel herstarten betekenen nog niet dat elke server naadloos kan worden bijgewerkt.

Het verschil is belangrijk omdat LUO niet zomaar een andere vorm van live patching is. Ksplice, kpatch en KernelCare maken het mogelijk om code in een lopende kernel te wijzigen. Ze zijn zeer nuttig voor het corrigeren van specifieke kwetsbaarheden zonder herstart, maar blijven de kernel zelf in essentie hetzelfde.

KHO en LUO bieden een andere operatie: daadwerkelijk een andere kernel opstarten via kexec, terwijl geprobeerd wordt delen van de benodigde staat over te brengen naar de nieuwe load.

Volgens de kerneldocumentatie wordt Live Update beschreven als een gespecialiseerd herstartproces op basis van kexec, dat in staat is om van de ene kernelversie naar de andere te schakelen terwijl bepaalde resources behouden blijven en compatibele apparaten operationeel blijven tijdens de overgang. De drijfveer achter de ontwikkeling hiervan is vooral het gebruik van Linux als hypervisor in grote cloud-omgevingen.

KHO is de geheugenbrug tussen twee kernels

kexec is geen nieuwe technologie. Linux kan al jaren een nieuwe kernel laden vanaf de huidige kernel, waardoor delen van het proces van een conventionele start worden vermeden zonder dat het hele firmware-proces opnieuw hoeft te worden doorlopen.

Het grote vraagstuk ligt bij de staat van de resources.

Een nieuwe kernel begint normaal gesproken vanaf een schone situatie. Gedeelten van geheugen en bepaalde resources die bij de vorige kernel hoorden, kunnen niet zomaar als geldig worden beschouwd.

Kexec HandOver (KHO) biedt daarvoor een infrastructuur om specifieke geheugenregio’s tijdens de overgang te behouden.

KHO werd geïntroduceerd in Linux 6.16 in 2025. De documentatie beschrijft het als een mechanisme dat in staat is om regio’s van geheugen, waaronder geserialiseerde systeemstatus, te behouden via een kexec-uitvoering.

De werking draait om een structuur genaamd Flattened Device Tree (FDT). De oude kernel geeft aan welke regio’s behouden moeten blijven, en die informatie wordt meegenomen tijdens de overgang. De nieuwe kernel kan later die regio’s vinden en de status reconstrueren.

In eenvoudige termen verloopt het proces als volgt:

Kernel Linux A
      │
      ├── Verwerpt overbodige status
      │
      └── Behoudt geheugen dat nodig is
                    │
                    ▼
                  KHO
                    │
                 kexec
                    │
                    ▼
Kernel Linux B
      │
      └── Herstelt de behouden regio’s

De huidige documentatie vereist dat de kernel is gecompileerd met:

CONFIG_KEXEC_HANDOVER=y

en dat KHO wordt ingeschakeld bij het opstarten met:

kho=on

Daarnaast kunnen aanvullende geheugenzones worden gereserveerd met kho_scratch. Een voorbeeld uit de kernel-documentatie is:

kho_scratch=16M,512M,256M

wat specifieke regio’s reservert die tijdens toekomstige kexec-operaties beschikbaar blijven.

Vervolgens kan de nieuwe kernel worden geladen met de kernel zelf via het loadercommando kexec_file:

kexec -l /pad/naar/bzImage --initrd /pad/naar/initrd -s

en vervolgens de overgang maken met:

kexec -e

De optie -s is daarbij relevant: volgens de documentatie ondersteunen user-space tools momenteel geen KHO-ondersteuning met de traditionele loader.

Maar KHO alleen lost niet alle problemen op.

Het kan geheugen aanleveren aan de nieuwe kernel, maar het moet nog duidelijk worden wat dat geheugen voorstelt, welke processen het gebruiken en hoe de resources die ervan afhangen kunnen worden herbouwd.

Daar komt LUO in beeld.

LUO probeert de lopende load ‘levend’ te houden tijdens de kernelwissel

De Live Update Orchestrator werd geïntroduceerd in Linux 6.19, gebaseerd op de basis die KHO heeft gelegd.

Het doel is het coördineren van het hele proces van resourcebehoud.

LUO beschikt over sessies die groepen resources omvatten die tijdens de overgang behouden moeten blijven. Een agent in gebruikersruimte gebruikt die sessies, voegt resources toe en serializeert de benodigde informatie zodra kexec wordt gestart.

Na het starten van de nieuwe kernel kan dezelfde sessie met een naam worden hergebruikt om resources te herstellen.

Het basisproces verloopt als volgt:

1. Maak LUO-sessie aan
2. Registreer resources
3. Bewaar status
4. Bevries benodigde elementen
5. Voer kexec uit
6. Start nieuwe kernel
7. Herstel sessie
8. Reconstrueer resources
9. Hervat de workload

De interface bevindt zich meestal op:

/dev/liveupdate

en wordt bestuurd via ioctl-aanroepen. Alleen één proces kan tegelijkertijd het /dev/liveupdate-bestand openen om conflicten te voorkomen.

LUO wordt ingeschakeld bij het opstarten met:

liveupdate=on

De huidige documentatie noemt expliciet subsystemen als KVM, IOMMU, interrupties, VFIO, geheugen en bepaalde bestandssystemen als deelnemers in het proces.

Dit verklaart ook waarom Google zo’n grote interesse heeft in dit project.

Het lastige geval: host upgraden zonder virtuele machines uit te schakelen

Stel dat je een fysieke server hebt met tientallen virtuele machines.

Er komt een kernel-kwetsbaarheid naar voren waarvoor een nieuwe versie moet worden geïnstalleerd.

De conventionele aanpak zou zijn om de virtuele machines te migreren of uit te schakelen, de host te upgraden en opnieuw op te starten.

In grote clouds brengt dat aanzienlijke kosten met zich mee.

• Het veroorzaakt niet alleen onderbrekingen, maar vereist ook extra capaciteit voor migraties, netwerkverkeer, operationele tijd en coördinatie van duizenden hosts.
• Bij GPU-servers wordt het nog complexer vanwege de hardwarekosten en de pass-through of VFIO-technologieën van de apparaten.

LUO richt zich op een scenario waarin de host kan worden geüpdatet zonder de VM’s te hoeven stoppen.

Een virtuele machine die wordt beheerd door QEMU/KVM houdt veel van haar state in geheugen en gebruikt kernelresources zoals memfd, VFIO of IOMMU.

Als die elementen tijdens kexec behouden kunnen blijven, kan de host:

oudere kernel
    │
    ├── QEMU
    │    └── lopende VM
    │
    ▼
behoud van geheugen en resources
    │
    ▼
kexec
    │
    ▼
nieuwe kernel
    │
    ├── resource-herstel
    │
    └── resources opnieuw toewijzen aan VM

De documentatie van LUO geeft expliciet aan dat het doel is om te zorgen dat resources zoals vfio, memfd en iommufd tijdens de overgang worden behouden. Sommige apparaten kunnen zelfs ondanks de kernelwissel DMA-activiteiten voortzetten.

Voor de gebruikers van de VM betekent dit dat de overstap van de hypervisor-kernel minimaal of vrijwel onmerkbaar moet zijn.

Dat staat in contrast met het gewoon toepassen van een patch op enkele functies.

De server draait feitelijk op een andere kernel.

Google heeft daarnaast luo-agent gepubliceerd om het proces te coördineren

De kernel biedt de infrastructuur, maar iemand in gebruikersruimte moet alles coördineren.

Google onderhoudt het open project googleprodkernel/luo-agent, geschreven in C en uitgebracht onder GPL-2.0.

Deze bevat twee hoofdonderdelen:

luod

is de daemon die /dev/liveupdate beheert.

En:

luoctl

is het beheertool dat wordt gebruikt om kernels te laden, sessies te beheren en de overgang te initiëren.

De architectuur is ontworpen om te vermijden dat elke applicatie het hele proces zelf moet controleren.

luod houdt de sessie in stand en client-processen, zoals een QEMU-proces, verbinden via een Unix-socket.

Het verwachte proces verloopt ongeveer als volgt:

Beheerder
     │
   luoctl
     │
     ▼
    luod
     │
     ├── QEMU client
     ├── Database
     └── Andere compatibele service
              │
              ▼
        LUO-sessies
              │
              ▼
           Kernel

Volgens de documentatie van het project verbinden clients zich met:

/run/luod/liveupdate.sock

en kunnen bestanden handles ontvangen via SCM_RIGHTS, een mechanisme waarmee bestandsdescriptors tussen processen kunnen worden doorgegeven.

Voordat de overgang plaatsvindt, ontvangt de client een verzoek tot resource-behoud, bewaart deze en geeft aan dat hij klaar is.

Na kexec kan hij zich met dezelfde identifier opnieuw aansluiten en de betreffende sessie ophalen.

Deze aanpak vermijdt het opleggen van een eenduidig staatformaat voor alle toepassingen, omdat elke client beter weet welke resources hij moet behouden dan het centrale orkest.

systemd 261 ondersteunt nu file descriptors bij LUO

LUO is niet meer louter een experimenteel Google-project.

De recente documentatie van Linux meldt dat systemd vanaf versie 261 ondersteuning biedt voor LUO en de mogelijkheid heeft om de opslag van file descriptors per service tijdens een kexec-update te behouden.

Services kunnen hiervoor opties gebruiken zoals:

FileDescriptorStoreMax=

en

FileDescriptorStorePreserve=

om aan te geven welke descriptors worden vastgehouden.

Dit is relevant omdat file descriptors meer zijn dan alleen nummers.

• open bestanden;
• pipes;
• bepaalde sockets;
• geheugen via memfd;
• resources van apparaten;
• LUO-sessies.

Het behouden hiervan betekent dat een nieuw uitgevoerde service na de overgang resources terug kan vinden die bij de vorige processen hoorden, zoals in het geval van in-memory-caches zoals memcached. De gigabytes aan data kunnen in een memfd blijven en zonder heropbouw worden hersteld.

Dit vergroot het belang van LUO aanzienlijk, niet alleen voor hypervisors maar mogelijk ook voor databasebeheer, containers en netwerktechnologieën.

Toekomstige toepassingen: databases, containers en netwerken

De documentatie bevestigt dat het ontwerp bedoeld is om onafhankelijk te zijn van de specifieke workload.

Het noemt expliciet:

• virtuele machines;
• containers;
• high-performance databases;
• netwerkservices;
• in-memory caches.

Echter, er is een belangrijk verschil tussen dat het framework deze workloads kan ondersteunen en dat ze automatisch volledige compatibiliteit bieden bij een kernelwissel.

LUO vereist controllers die in staat zijn de verschillende resource-typen te serialiseren en reconstrueren.

Daarom omvat de architectuur functies als:

can_preserve()
preserve()
freeze()
retrieve()
finish()

De oude kernel moet weten hoe hij de status serialiseert, en de nieuwe kernel moet die weer kunnen reconstrueren.

Het is een uitbreidbare infrastructuur, geen universele time-machine voor alle Linux-processen.

In dat opzicht kan het worden aangevuld met een andere technologie: CRIU (Checkpoint/Restore in Userspace).

CRIU maakt het mogelijk de toestand van processen te capturen en later weer te herstellen. Het wordt bijvoorbeeld gebruikt voor migratie en checkpointing van containers.

KHO, LUO en CRIU opereren op verschillende lagen, maar samen bieden ze de mogelijkheid om een deel van de toestand in RAM te laten, terwijl andere delen worden geserialiseerd en vanaf gebruikersruimte worden hersteld.

Nog is er werk te verzetten voordat dit soort scenario’s voor elke toepassing transparant kunnen worden gemaakt.

Het is niet zomaar een “reboot-less” upgrade

Hier is een belangrijke nuance.

Het beweren dat LUO het mogelijk maakt om de kernel te veranderen “zonder te herstarten” is begrijpelijk als samenvatting, maar kan technisch misleidend zijn.

Het kernelherstartproces blijft bestaan.

LUO gebruikt kexec.

De oude kernel stopt met draaien en een nieuwe kernel wordt gestart.

Wat men probeert te voorkomen, is de volledige traditionele herstart van de machine, inclusief onderbreking van workloads en de services die erop draaien.

In plaats daarvan gaat het om:

oude kernel
      │
    kexec
      │
nieuwe kernel

en KHO/LUO proberen voldoende toestand tussen beide over te dragen.

Deze precisering is belangrijk omdat het de grenzen van de technologie markeert.

Een wijziging van firmware, hardware-aanpassingen of andere problemen die fysiek opnieuw opstarten vereisen, blijven buiten dit proces om.

LUO vervangt niet de live patching

Technologieën zoals Kpatch, Ksplice en vergelijkbare blijven relevant.

Ze lossen verschillende behoeften op dan LUO.

Het live patchen zou bijvoorbeeld zijn:

Kernel 6.x
   │
breng patch toe
   │
Kernel 6.x met wijzigingen

LUO daarentegen volgt dit patroon:

Kernel A
   │
behoud resources
   │
kexec
   │
Kernel B

Voor kleine kwetsbaarheden kan het aanbrengen van patches minder riskant zijn dan het volledig vervangen van de kernel.

Echter, live patching heeft beperkingen.

Niet elke wijziging kan eenvoudig worden gepatcht, en na verloop van tijd kunnen er afwijkingen ontstaan tussen de kernel die is opgestart en de gemodificeerde versie.

Een volledige transitie biedt de mogelijkheid om daadwerkelijk de kernel te draaien die alle patches bevat.

Daarom kunnen beide technologieën samen worden ingezet: live patching voor snelle mitigaties en LUO voor een volledige update met minimale onderbrekingen.

Nog niet voor productie geschikt zonder voorzichtigheid

Hoewel de technologie inmiddels in de hoofdkernel is opgenomen, is ze nog jong.

De officiële documentatie over de API van Live Update waarschuwt expliciet dat het nog in ontwikkeling is en dat compatibiliteit bij overgang tussen verschillende kernelversies nog niet gegarandeerd kan worden. Die stabiliteit wordt gepland voor latere fases.

KHO bevat ook debug-interfaces die volgens de documenten kunnen veranderen naarmate het subsysteem stabieler wordt.

Het vinden van CONFIG_KEXEC_HANDOVER of LUO-ondersteuning in een distributie betekent dus niet automatisch dat deze mechanismen meteen klaar zijn voor kritische systemen.

De huidige luo-agent-repository, bijvoorbeeld, vereist een Linux-kernel van 6.19 of hoger met CONFIG_LIVEUPDATE ingeschakeld.

Voor tests wordt vaak een opstartconfiguratie gebruikt zoals:

kho=on
kho_scratch=16M,512M,256M
liveupdate=on

maar dat activeert alleen de kernelcomponenten. Het behouden van resources hangt af van ondersteuning in de gebruikte software.

Waarom deze technologie nu belangrijker is dan tien jaar geleden

Het probleem van kernelherstarten is niet nieuw.

Wat veranderd is, is de omvang van de infrastructuur die afhangt van Linux.

• Een cloudprovider heeft mogelijk duizenden fysieke hypervisors, die tientallen of honderden VM’s draaien.
• Bij grote incidenten met kwetsbaarheden is een herstart niet zomaar een kwestie van ’s nachts een update plannen.
• Het vereist het evacueren en migreren van VM’s, het vrijmaken van capaciteit, coördinatie van updates, en herintroductie van workloads.
• In dat proces spelen vooral ook de kosten, tijd en risico’s een grote rol.

Daarnaast maken hardwarebeperkingen en de complexiteit van devices zoals GPU’s het proces nog moeilijker.

De snelheid waarmee kwetsbaarheden worden ontdekt, mede door geavanceerde automatisering en AI, verhoogt de druk om snel te kunnen reageren.

Hoe sneller en makkelijker het is om snel een kernel met patches te updaten, des te minder impetus blijft bestaan om te wachten met grotere upgrades.

Dat is waarschijnlijk de ware betekenis achter de ontwikkeling van KHO en LUO.

Het gaat niet om te stellen dat Linux nooit meer opnieuw hoeft te worden opgestart.

Het is eerder proberen te scheiden wat tot nu toe altijd samenhing: de kernel updaten en de workload onderbreken.

Als die scheiding stabiel blijkt te werken, bijvoorbeeld met virtuele machines, hardware, containers en netwerken, dan zou een kernelupdate vergelijkbaar kunnen worden met regulier onderhoud.

Dat moment is nog niet bereikt.

Maar sinds Linux 6.16 met KHO, Linux 6.19 met LUO en systemd 261 dat ondersteuning voor bestandsdescriptors integreert, worden de fundamenten niet langer uitsluitend in experimenten ontwikkeld, maar maken ze deel uit van de standaard Linux-infrastructuur.

Veelgestelde vragen

Kan Linux momenteel al elke kernel zonder herstart bijwerken?

Niet volledig en naadloos voor alle systemen. KHO en LUO maken een overgang mogelijk via kexec waarbij bepaalde staten en resources worden overgedragen, maar vereisen uitgebreide ondersteuning in kernel, gebruikersruimte en applicaties.

Wat is het verschil tussen LUO en Kpatch of Ksplice?

Kpatch en Ksplice passen code in een lopende kernel aan, terwijl LUO een andere kernel opstart en probeert resources te behouden voor minimale onderbreking.

Welke Linux-versies bevatten KHO en LUO?

Kexec HandOver werd geïntroduceerd in Linux 6.16, LUO kwam in Linux 6.19, en systemd 261 heeft LUO-integratie.

Wat doet de luo-agent van Google?

luo-agent is de gebruikersruimtecomponent die LUO coördineert. Het omvat de daemon luod en de tool luoctl voor loading, sessiebeheer en het initiëren van de overgang via kexec.

Bronnen:

• Linux Kernel Documentation, Kexec HandOver (KHO).
• Linux Kernel Documentation, Live Update Orchestrator en Live Update uAPI.
• Google Production Kernel, open source project luo-agent op GitHub.
• systemd 261, integratie van File Descriptor Store met LUO.
• Phoronix, rapporten over integratie van KHO en LUO in Linux releases.