Live kernel patching op een VPS: is een reboot nodig?

Wat live kernel patching doet op een VPS

Live kernel patching past beveiligingsupdates voor de kernel toe op een draaiende machine, zonder herstart en zonder verbroken verbindingen. Een gecorrigeerde kopie van een functie wordt als kernelmodule geladen en elke aanroep naar de oude functie wordt omgeleid naar de nieuwe kopie, terwijl de server verkeer blijft afhandelen. Dat ene mechanisme verklaart zowel waar live patching goed in is als wat het niet kan.

Het koopt tijd. Het vervangt de herstart niet. Een server die zes maanden lang via live patching is bijgewerkt, draait nog steeds op de oude kernel-image op de schijf, en al die patches bevinden zich uitsluitend in het geheugen.

Live patching wordt vaak verkocht als een functie van een managed plan. Op een unmanaged server schakelt u dit zelf in met twee commando's; het is nuttig om dit te weten voordat u betaalt voor het verschil tussen een managed en een unmanaged VPS.

Hoe werkt live kernel patching?

De kernel beschikt over een ingebouwde kern voor live patching, die wordt meegecompileerd met CONFIG_LIVEPATCH. Controleer uw actieve kernel hierop:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

Een regel met CONFIG_LIVEPATCH=y betekent dat de kernel die u draait, is gebouwd met de aanwezige kern. Zonder deze optie kan geen enkele live patching-service op die machine functioneren.

De omleiding zelf maakt gebruik van ftrace, de functie-tracer van de kernel. De meeste kernelfuncties worden gecompileerd met een call-instructie aan het begin van de functie, nog voordat de argumenten of de stack zijn aangeraakt. Ftrace gebruikt die call-locatie als hook. Wanneer een patch wordt toegepast, registreert de live patching-kern een ftrace-handler op de doelfunctie, en de handler stuurt de uitvoering vervolgens door naar de vervangende functie. De kernel-documentatie verwoordt het helder: "Livepatching moet doorgaans de code aan het begin van de functie-entry omleiden voordat de functieparameters of de stack op enige wijze zijn gewijzigd."

Uit die zin volgen twee consequenties die later van belang zijn. Alleen een functie die ftrace kan hooken is patchbaar; een functie die is gecompileerd zonder die entry-call kan dus helemaal niet worden gepatcht. Bovendien is de eenheid van patching een volledige functie, nooit een enkele regel binnen een functie.

Het lastigste onderdeel is het veilig omschakelen van een live systeem. Als oude code nog op de stack van een CPU draait op het moment dat u de functie vervangt, krijgt u een mix van oud en nieuw gedrag. Upstream Linux handelt dit af met een consistentiemodel per taak, in de kernel-documentatie omschreven als een hybride vorm: "het gebruikt de consistentie per taak en syscall-barrière-omschakeling van kGraft, gecombineerd met de stack trace-omschakeling van kpatch." Taken gaan één voor één over naar de nieuwe code, en alleen wanneer de kernel kan aantonen dat de taak zich op dat moment niet in een gepatchte functie bevindt. Totdat elke taak is overgegaan, bevindt de patch zich in een overgangsfase.

U kunt het resultaat zelf inzien. Toegepaste patches verschijnen onder /sys/kernel/livepatch, met één map per patch, waarin de gepatchte functies worden vermeld.

ls /sys/kernel/livepatch/

Een lege lijst betekent dat er geen live patch in het geheugen is geladen, wat op een nieuwe server de normale begintoestand is.

Wat live kernel patching niet kan oplossen

Functie-bodies worden gepatcht. Al het overige niet.

• Gewijzigde datastructuren. Als de upstream-fix een veld toevoegt aan een struct of de betekenis van een bestaand veld wijzigt, is er geen veilige manier om objecten die al zijn toegewezen en in gebruik zijn te herschrijven. Het kpatch-project stelt het equivalente geval direct: "Patches die statisch toegewezen data wijzigen, worden niet direct ondersteund." Shadow variables en callbacks bestaan als workaround, maar deze worden per patch handmatig geschreven en zijn niet automatisch.
• Fixes verspreid over meerdere functies tegelijk. Een fix die de lock-volgorde over een groep functies wijzigt, vereist dat deze allemaal tegelijk veranderen. Het consistentiemodel schakelt taken om in plaats van de gehele machine op één enkel moment te bevriezen.
• Initialisatiecode. Functies gemarkeerd met __init zijn al uitgevoerd en vrijgegeven tegen de tijd dat uw server is opgestart; er is dus niets meer om naar door te verwijzen.
• Nieuwe kernelversies en nieuwe functies. Live patching verplaatst u binnen een kernelserie naar een volgend patchniveau. Het verplaatst u nooit van de ene serie naar de volgende en voegt nooit functies toe. Als u iets wilt uit een nieuwere serie, zoals de wijzigingen die in Linux 7.1 zijn doorgevoerd, installeert u die kernel en start u deze op.
• Userspace. Canonical stelt de grens zelf vast: "Canonical Livepatch patcht geen userspace-libraries zoals OpenSSL of glibc, omdat dat de verantwoordelijkheid is van unattended-upgrades of een systeembeheertool." Een live gepatchte kernel naast een verouderde OpenSSL betekent geen gepatchte server; zorg er dus voor dat unattended upgrades de userspace-pakketten afhandelt op dezelfde machine.

Er is ook een ernstgrens bij de dienst van Ubuntu. Canonical zegt dat het "kernelkwetsbaarheden patcht met critical en high Common Vulnerability Scoring System (CVSS) en Ubuntu Priority-beoordelingen." Een CVE (common vulnerabilities and exposures)-identificatie benoemt één fout, en CVSS is de score die daaraan is gekoppeld. Een kernel-CVE met een medium-beoordeling wordt in het pakket op schijf opgelost en wordt niet live gepatcht; deze bereikt uw draaiende kernel pas bij de volgende herstart en niet eerder.

Wat zijn de opties voor live kernel patching?

Er zijn drie gangbare methoden in gebruik, die allemaal gebruikmaken van hetzelfde kernelmechanisme.

Canonical Livepatch wordt geleverd via Ubuntu Pro. Ubuntu Pro is gratis voor persoonlijk gebruik, waarbij Canonical aangeeft dat het "altijd gratis zal blijven voor persoonlijk gebruik op maximaal 5 fysieke machines", oplopend tot 50 machines voor officiële leden van de Ubuntu Community. Dit is de gedocumenteerde limiet per augustus 2026. Commercieel gebruik vereist een betaald abonnement. Dekking wordt verleend per kernelserie en per variant, inclusief de general availability (GA) kernels van de ondersteunde long term support (LTS) releases, evenals de hardware enablement (HWE) kernels, voor varianten zoals generic, aws, azure, gcp, oracle, ibm en lowlatency. Controleer uw eigen kernel aan de hand van de gepubliceerde kernellijst van Canonical voordat u hierop vertrouwt.

KernelCare, van TuxCare, is een commerciële agent die vele distributies ondersteunt, inclusief distributies zonder eigen patch-service. De gedocumenteerde installatie verloopt via een script van de leverancier, curl -s -L https://kernelcare.com/installer | bash, gevolgd door /usr/bin/kcarectl --register KEY voor een licentie op basis van een sleutel. De agent controleert vervolgens volgens een eigen schema op nieuwe patches, en /usr/bin/kcarectl --update dwingt een controle af. Lees het installatiescript door voordat u dit via een pipe naar een shell stuurt op een server die u belangrijk vindt.

kpatch en kGraft zijn de voorlopers. kGraft kwam van SUSE, kpatch van Red Hat, en de huidige live patching-kern in de upstream Linux-kernel is een samenvoeging van beide concepten. kpatch zelf wordt afgebouwd: in de README staat dat het kpatch-project vanaf Linux 6.19 "verouderd is en in onderhoudsmodus staat", waarbij kpatch-build wordt vervangen door klp-build in de upstream-kernel. Op RHEL en de daarvan afgeleide distributies is de aanbevolen tool de eigen service van de distributie, in plaats van het handmatig bouwen van patches.

Maak uw keuze op basis van wat uw distributie ondersteunt en wat uw licentie toestaat. Het resultaat op kernelniveau is in elk geval hetzelfde.

Canonical Livepatch inschakelen op Ubuntu

Haal eerst een token op via uw Ubuntu Pro-accountpagina. Beide onderstaande commando's vereisen een werkende uitgaande netwerkverbinding, omdat de client contact maakt met de servers van Canonical om het systeem te koppelen en patches op te halen.

sudo pro attach TOKEN
sudo pro status

Het uitvoeren van sudo pro attach zonder token start een browsergebaseerd proces en toont een code die u op de website van Canonical moet invoeren. Bij het koppelen worden de aanbevolen services automatisch ingeschakeld; op een huidige LTS-release is dit inclusief Livepatch. Gebruik sudo pro attach --no-auto-enable als u de services liever handmatig wilt selecteren.

Als Livepatch nog niet is ingeschakeld:

sudo pro enable livepatch
sudo canonical-livepatch status

De service draait vanuit de canonical-livepatch snap, dus snapd moet functioneren om de inschakelstap te voltooien. pro status toont een tabel met services, hun recht op gebruik en hun status. canonical-livepatch status toont de details per kernel, en de documentatie van Canonical toont de output in deze vorm:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

Twee regels bevatten het antwoord. kernel state geeft aan of de serie die u draait überhaupt door de service wordt ondersteund; dit is de regel die verandert wanneer u opstart met een kernel die niet door Livepatch wordt ondersteund. patch state geeft aan of de patches die van toepassing zijn op die kernel daadwerkelijk zijn geladen. Een ondersteunde kernel zonder toegepaste patches duidt op een probleem met de client. Een niet-ondersteunde kernel is een kernelprobleem en kan niet worden opgelost met clientinstellingen.

Hoe stel ik vast of een herstart in de wacht staat?

Live patching neemt de urgentie weg, waardoor een in de wacht staande herstart niet langer direct zichtbaar is. U moet hier actief naar zoeken.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

De pakketbeheerder maakt /var/run/reboot-required aan wanneer een geïnstalleerd pakket een herstart vereist om effectief te worden; een nieuw linux-image-pakket creëert dit bestand altijd. Het bestand .pkgs bevat een lijst met pakketten die om een herstart hebben verzocht. Als het eerste commando No such file or directory als resultaat geeft, heeft niets sinds de laatste keer opstarten om een herstart gevraagd. Op huidige Ubuntu-versies is /var/run een symbolische link naar /run, dus beide paden verwijzen naar hetzelfde bestand.

Deze vlag bevindt zich in een tmpfs en wordt bij elke boot gereset, dus controleer dit ook aan de hand van de kernel zelf:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r toont de kernel die momenteel actief is. Het tweede commando toont de kernelpakketten die op de schijf zijn geïnstalleerd. Een linux-image in die lijst die nieuwer is dan wat uname -r rapporteert, betekent dat de machine op een oude kernel draait, ongeacht wat de status van Livepatch aangeeft. Dit is de controle die ertoe doet, omdat live patching is ontworpen om de actieve kernel veilig te houden, niet om deze up-to-date te houden.

Voor het userspace-gedeelte van dezelfde vraag: needrestart is standaard geïnstalleerd op Ubuntu Server en toont de actieve services die nog steeds verwijderde bibliotheekbestanden in gebruik hebben.

sudo needrestart -r l

Het vlaggenpaar -r l betekent "alleen weergeven", waardoor het niets rapporteert of wijzigt.

Waarom een reboot altijd noodzakelijk blijft

De kernel op de schijf blijft ongewijzigd. Live patches worden in de actieve kernel geladen en nooit naar de boot-image geschreven. Een reboot zorgt er dus voor dat u opstart met de linux-image die de bootloader selecteert, waarna de Livepatch-client de nog relevante patches opnieuw toepast. Tussen die twee momenten draait u ongepatchte code; dit is een extra reden om een actuele kernel op te starten in plaats van een oude.

Dekking geldt per kernel-serie en series worden na verloop van tijd uitgefaseerd. Wanneer uw actieve serie niet langer op de lijst met ondersteunde versies staat, stopt de kernel state-regel met het rapporteren van dekking. De enige oplossing is dan een nieuwere kernel. Dat vereist een reboot. Bij een LTS-release bereikt de nieuwere serie u meestal als een hardware enablement kernel, gebundeld in een point release zoals 26.04.1. De vervanging staat dan al in het archief en het enige wat nog ontbreekt, is een reboot die u zelf inplant.

Kernel-fixes met een gemiddelde of lage prioriteit worden nooit via live patching doorgevoerd. Deze bevinden zich in het pakket op de schijf en bereiken u pas zodra u opnieuw opstart.

Kernels die langdurig draaien, verzamelen bovendien een status die patching niet opschoont. Het standpunt van Canonical is het vermelden waard, omdat het eerlijk is: Livepatch "is geen vervanging voor een reboot. Het is een tool die u meer controle geeft door ongeplande reboots te voorkomen." Het woord dat hier de kern raakt, is ongepland. U moet nog steeds rebooten. U bepaalt alleen wanneer.

Een herstart plannen die ook weer opkomt

Een VPS-herstart is eenrichtingsverkeer als u de console niet kunt bereiken. Voordat u reboot typt, moet u zeker weten dat u weer toegang krijgt als de machine niet terugkeert.

• Controleer of uw provider een seriële console of VNC (virtual network computing) aanbiedt in het configuratiescherm en open deze nu, in plaats van tijdens de storing.
• Controleer de vrije schijfruimte met df -h /boot. Een volle /boot zorgt ervoor dat het kernel-pakket faalt bij het schrijven van de initramfs (initial RAM filesystem), waardoor een bootloader-vermelding kan verwijzen naar een onvoltooid image.
• Houd ten minste één oudere, werkende kernel geïnstalleerd. GRUB toont deze onder "Advanced options for Ubuntu"; opstarten vanaf deze versie is het snelste herstel wanneer een nieuwe kernel faalt.
• Zoek de rescue-modus van uw provider op voordat u deze nodig heeft. Als de console na de herstart een initramfs-prompt toont, is dat de plek waar de reparatie plaatsvindt.

Plan de herstart vervolgens op een tijdstip waarop u wakker bent:

sudo shutdown -r +5 "Kernel update, back in a moment"

Dit plant de herstart over vijf minuten in en stuurt een bericht naar ingelogde gebruikers. sudo shutdown -c annuleert de opdracht. Wanneer de machine terugkeert, controleert u beide onderdelen:

uname -r
sudo canonical-livepatch status

uname -r hoort nu de nieuwere kernel te tonen en de statusuitvoer hoort de nieuwe reeks als gedekt aan te geven. Als de machine helemaal niet terugkeert, ligt de fout bijna altijd in het opstartpad in plaats van in het netwerk. De herstelroute vindt u in de handleiding voor een VPS die niet opstart na een kernel-update.

Waarom oude kernels moeten worden opgeruimd

Live patching verergert dit probleem in plaats van het te verhelpen, omdat de noodzaak om opnieuw op te starten vervalt terwijl linux-image-pakketten worden geïnstalleerd. Elke kernel installeert een boot-image, een initramfs, een modules-tree en meestal een headers-pakket. Op een kleine VPS met een afzonderlijke /boot-partitie van enkele honderden megabytes, vullen drie of vier van deze kernels de schijfruimte volledig.

Een volle /boot zorgt er vervolgens voor dat de volgende kernel-installatie mislukt. Hierdoor kan een machine de update die juist nodig is, niet meer installeren. Het apt autoremove-pad verwijdert oude kernels zodra deze in aanmerking komen, maar op een machine die nooit opnieuw opstart, is dit niet altijd het geval. De pakketbeheerder verwijdert namelijk geen kernel die mogelijk nog actief is.

Controleer daarom welke kernels zijn geïnstalleerd, behoud de actieve kernel en één werkend reserve-exemplaar, en verwijder de rest via de veilige procedure voor het verwijderen van oude kernels op Ubuntu. Verwijder nooit de kernel die uname -r op dit moment rapporteert.

FAQ

Betekent live kernel patching dat ik mijn VPS nooit hoef te herstarten?

Nee. Live patches worden in de actieve kernel geladen en niet naar de boot-image geschreven, waardoor de linux-image op schijf op de versie blijft staan waarmee u bent opgestart. Canonical stelt dit expliciet: Livepatch "is geen vervanging voor een herstart. Het is een hulpmiddel dat u meer controle geeft door ongeplande herstarts te voorkomen." De dekking vervalt bovendien wanneer uw kernel-serie wordt uitgefaseerd, en kernel-fixes met een gemiddelde ernst worden nooit via live patching verwerkt. Plan een onderhoudsherstart in op een door u gekozen moment in plaats van te wachten tot dit wordt afgedwongen.

Hoe controleer ik of live kernel patching daadwerkelijk patches toepast?

Voer sudo canonical-livepatch status uit en lees de twee regels. kernel state rapporteert of uw actieve kernel-serie door de service wordt gedekt, en patch state rapporteert of de patches voor die kernel zijn geladen. U kunt de kernel-zijde ook direct controleren met ls /sys/kernel/livepatch/, die één map per geladen patch weergeeft. Een lege lijst betekent dat er op dit moment niets in het geheugen is gepatcht, ongeacht wat de client aangeeft.

Is Ubuntu Pro gratis op een persoonlijke VPS?

Ja, binnen een gedocumenteerde limiet. De bewoording van Canonical is dat Ubuntu Pro "gratis is en altijd gratis zal blijven voor persoonlijk gebruik op maximaal 5 fysieke machines", oplopend tot 50 machines voor officiële Ubuntu Community-leden, per augustus 2026. Commercieel gebruik vereist een betaald abonnement. U koppelt een machine met sudo pro attach TOKEN met een token van uw Ubuntu Pro-accountpagina en schakelt vervolgens de service in met sudo pro enable livepatch.

Waarom staat een kernel-CVE nog steeds als niet-gepatcht vermeld nadat Livepatch is uitgevoerd?

Dit heeft meestal een van de twee volgende redenen. De fix kan onder de drempelwaarde voor ernst vallen, omdat Canonical alleen "kernel-kwetsbaarheden met een kritieke of hoge Common Vulnerability Scoring System (CVSS) en Ubuntu Priority-classificatie" via live patching verwerkt en de rest overlaat aan het pakket op schijf. Of de fix kan niet worden uitgedrukt als een wijziging aan een functie-body, bijvoorbeeld wanneer upstream een datastructuur heeft gewijzigd, wat live patching niet veilig kan uitvoeren op objecten die al zijn toegewezen. Beide gevallen worden op dezelfde manier opgelost: installeer het bijgewerkte kernel-pakket en start hiernaar op.

Wat dekt live kernel patching helemaal niet?

Userspace. Canonical is expliciet dat Livepatch "geen userspace-bibliotheken zoals OpenSSL of glibc patcht, omdat dat de verantwoordelijkheid is van unattended-upgrades of een systeembeheertool." Het kan ook geen nieuwe kernel-versie of nieuwe functionaliteit leveren, aangezien het alleen functie-bodies vervangt binnen de serie die u al draait. En het kan geen __init-functies patchen, die al zijn uitgevoerd en uit het geheugen zijn vrijgegeven tegen de tijd dat de server actief is.