Live kernel patching op een VPS: wanneer herstarten?

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, gecompileerd 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 kern 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 aanroepinstructie aan het begin van de functie, nog voordat de argumenten of de stack zijn aangeraakt. Ftrace gebruikt die aanroeplocatie als hook. Wanneer een patch wordt toegepast, registreert de live patching-kern een ftrace-handler op de doelfunctie, en de handler stuurt de uitvoering in plaats daarvan naar de vervangende functie. De kerneldocumentatie verwoordt het helder: "Livepatching moet doorgaans de code omleiden aan het begin van de functie-entry, voordat de functieparameters of de stack op enigerlei wijze zijn gewijzigd."

Uit die zin volgen twee consequenties, die beide later van belang zijn. Alleen een functie die ftrace kan hooken is patchbaar; een functie die is gecompileerd zonder die entry-aanroep 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 wanneer u de functie verwisselt, krijgt u een mix van oud en nieuw gedrag. Upstream Linux handelt dit af met een consistentiemodel per taak, in de kernel-documentatie beschreven als een hybride vorm: "het gebruikt de consistentie per taak en syscall-barrière-switching van kGraft, gecombineerd met de stack trace-switching van kpatch." Taken verplaatsen zich één voor één naar de nieuwe code, alleen wanneer de kernel kan aantonen dat die taak zich momenteel niet in een gepatchte functie bevindt. Totdat elke taak is verplaatst, bevindt de patch zich in een overgangsfase.

U kunt het resultaat zelf bekijken. Toegepaste patches verschijnen onder /sys/kernel/livepatch, één map per patch, met de gepatchte functies daarin 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 dit 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 tussen taken 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 één kernelserie naar een volgend patchniveau. Het verplaatst u nooit van de ene serie naar de volgende en voegt nooit functies toe. Als u iets uit een nieuwere serie wilt, 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-bibliotheken 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 grens wat betreft de ernst van de kwetsbaarheden in de service van Ubuntu. Canonical zegt dat het "kernelkwetsbaarheden patcht met een kritieke of hoge Common Vulnerability Scoring System (CVSS)-score en Ubuntu Priority-classificaties." Een CVE (common vulnerabilities and exposures)-identificatie benoemt één fout, en CVSS is de score die daaraan is gekoppeld. Een kernel-CVE met een gemiddelde score wordt in het pakket op schijf opgelost en niet via live patching; 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 stelt dat het "altijd gratis zal blijven voor persoonlijk gebruik op maximaal 5 fysieke machines", oplopend tot 50 machines voor officiële Ubuntu Community-leden. Dat is de gedocumenteerde limiet per augustus 2026. Commercieel gebruik vereist een betaald abonnement. Dekking wordt verleend per kernelserie en per variant, waarbij de general availability (GA) kernels van de ondersteunde long term support (LTS) releases worden gedekt, evenals hun 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 ondersteuningsdienst. De gedocumenteerde installatie verloopt via een leveranciersscript, 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 op een server stuurt 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: de README vermeldt dat vanaf Linux 6.19 "het kpatch-project is verouderd 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 tool die u moet gebruiken de eigen dienst van de distributie, in plaats van handmatig patches te bouwen.

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 liever zelf de services kiest.

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, inclusief hun rechten en 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 op die kernel van toepassing zijn, daadwerkelijk zijn geladen. Een ondersteunde kernel zonder toegepaste patches duidt op een probleem met de client. Een niet-ondersteunde kernel duidt op een kernelprobleem, wat niet kan worden opgelost met client-instellingen.

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 een herstart hebben aangevraagd. Als het eerste commando No such file or directory als antwoord geeft, heeft niets sinds de laatste keer opstarten om een herstart verzocht. Op huidige Ubuntu-systemen 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 tegenover 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 de status van Livepatch. 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 brengen.

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

sudo needrestart -r l

Het vlagpaar -r l betekent "alleen weergeven" (list only), waardoor het enkel rapporteert en niets wijzigt.

Waarom een reboot altijd noodzakelijk blijft

De kernel op de schijf blijft ongewijzigd. Live patches worden in de actieve kernel geladen en worden nooit naar de boot-image geschreven. Een reboot zorgt er dus voor dat u opstart met de kernel die linux-image door de bootloader wordt gekozen, waarna de Livepatch-client de toepasbare patches opnieuw installeert. Tussen deze twee momenten draait u ongepatchte code; dit is een extra reden om een actuele kernel te booten in plaats van een verouderde versie.

Dekking is gebonden aan een kernel-serie, en series worden na verloop van tijd uitgefaseerd. Wanneer uw actieve serie niet langer wordt ondersteund, stopt de kernel state-regel met het rapporteren van dekking. De enige oplossing is dan een nieuwere kernel. Dat vereist een reboot.

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

Kernels die langdurig draaien, verzamelen bovendien een status die patching niet opschoont. Het standpunt van Canonical is hierbij het vermelden waard, omdat het eerlijk is: Livepatch "is geen vervanging voor een reboot. Het is een hulpmiddel dat u meer controle geeft door ongeplande reboots te voorkomen." Het kernwoord in deze stelling 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 uitval.
• Controleer de vrije schijfruimte met df -h /boot. Een volle /boot zorgt ervoor dat het kernelpakket 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 vermeldt deze onder "Advanced options for Ubuntu"; het opstarten hiervan is het snelste herstel wanneer een nieuwe kernel faalt.
• Zoek de rescue mode 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 deze actie. Wanneer de machine terugkeert, controleert u beide onderdelen:

uname -r
sudo canonical-livepatch status

uname -r zou nu de nieuwere kernel moeten rapporteren en de statusuitvoer zou moeten aangeven dat de nieuwe serie wordt ondersteund. Als de machine helemaal niet terugkeert, ligt de fout bijna altijd in het opstartpad in plaats van in het netwerk, en de herstelroute is die 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 module-boom 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 systeem dat 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 momenteel rapporteert.

FAQ

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

Nee. Live patches worden in de actieve kernel geladen en niet naar de boot-image geschreven, dus de linux-image op de schijf blijft op de versie 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 een herstart noodzakelijk wordt.

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 dienst wordt ondersteund, en patch state rapporteert of de patches voor die kernel zijn geladen. U kunt ook direct aan de kernel-zijde controleren met ls /sys/kernel/livepatch/, wat één map per geladen patch weergeeft. Een lege lijst betekent dat er momenteel 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 dienst in met sudo pro enable livepatch.

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

Dit heeft meestal een van de twee volgende redenen. De fix kan onder de ernst-drempel 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 de schijf. Of de fix kan niet worden uitgedrukt als een wijziging in 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. Daarnaast kan het geen __init-functies patchen, die al zijn uitgevoerd en uit het geheugen zijn vrijgegeven tegen de tijd dat de server operationeel is.