Live-Kernel-Patching oder Neustart beim VPS

Was Live-Kernel-Patching auf einem VPS bewirkt

Live-Kernel-Patching wendet Kernel-Sicherheitskorrekturen auf ein laufendes System an, ohne Neustart und ohne abgebrochene Verbindungen. Eine korrigierte Kopie einer Funktion wird als Kernelmodul geladen. Jeder Aufruf der alten Funktion wird an die neue Kopie umgeleitet, während der Server weiterhin Netzwerkverkehr verarbeitet. Dieser Mechanismus erklärt sowohl, wofür Live-Patching geeignet ist, als auch, was damit nicht möglich ist.

Es verschafft Zeit. Den Neustart ersetzt es nicht. Ein Server, der sechs Monate lang per Live-Patching aktualisiert wurde, läuft weiterhin mit dem alten Kernel-Image auf der Festplatte. Jede dieser Korrekturen befindet sich nur im Arbeitsspeicher.

Live-Patching wird häufig als Funktion eines Managed-Tarifs angeboten. Auf einem nicht verwalteten Server aktivieren Sie es mit zwei Befehlen selbst. Das sollten Sie wissen, bevor Sie für den Unterschied zwischen einem verwalteten und einem nicht verwalteten VPS bezahlen.

Wie funktioniert Live-Kernel-Patching?

Der Kernel verfügt über einen integrierten Kern für Live-Patching, der mit CONFIG_LIVEPATCH einkompiliert wird. Prüfen Sie, ob der laufende Kernel diese Funktion enthält:

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

Eine Zeile mit CONFIG_LIVEPATCH=y bedeutet, dass der laufende Kernel mit diesem integrierten Kern erstellt wurde. Ohne ihn kann kein Live-Patching-Dienst auf diesem Rechner arbeiten.

Die eigentliche Umleitung verwendet ftrace, den Funktionstracer des Kernels. Die meisten Kernel-Funktionen werden mit einer Aufrufanweisung ganz am Anfang der Funktion kompiliert, bevor die Argumente oder der Stack verändert wurden. ftrace verwendet diese Aufrufstelle als Hook. Beim Anwenden eines Patches registriert der Live-Patching-Kern einen ftrace-Handler für die Zielfunktion. Der Handler leitet die Ausführung stattdessen an die Ersatzfunktion weiter. Die Kernel-Dokumentation formuliert es eindeutig: „Livepatching muss den Code typischerweise ganz am Anfang des Funktionseinstiegs umleiten, bevor die Funktionsparameter oder der Stack in irgendeiner Weise verändert wurden.“

Aus diesem Satz ergeben sich zwei wichtige Konsequenzen. Nur eine Funktion, die ftrace mit einem Hook versehen kann, ist patchbar. Eine Funktion, die ohne diese Aufrufanweisung am Einstieg kompiliert wurde, kann überhaupt nicht gepatcht werden. Außerdem ist die gesamte Funktion die Einheit des Patches, niemals eine einzelne Zeile innerhalb der Funktion.

Schwieriger ist der sichere Wechsel bei einem laufenden System. Wenn alter Code beim Austausch der Funktion noch auf dem Stack einer CPU ausgeführt wird, entsteht eine Mischung aus altem und neuem Verhalten. Das Upstream-Linux löst dies mit einem Konsistenzmodell pro Task, das in der Kernel-Dokumentation als Hybridmodell beschrieben wird: „Es verwendet die Konsistenz pro Task und die Umschaltung an der Systemaufrufbarriere von kGraft in Kombination mit der Stack-Trace-Umschaltung von kpatch.“ Tasks wechseln einzeln zum neuen Code, und zwar erst, wenn der Kernel nachweisen kann, dass sich der jeweilige Task derzeit nicht innerhalb einer gepatchten Funktion befindet. Solange noch nicht jeder Task gewechselt hat, befindet sich der Patch im Übergangszustand.

Das Ergebnis können Sie selbst prüfen. Angewendete Patches erscheinen unter /sys/kernel/livepatch. Für jeden Patch gibt es dort ein eigenes Verzeichnis. Die gepatchten Funktionen sind darin aufgeführt.

ls /sys/kernel/livepatch/

Eine leere Ausgabe bedeutet, dass kein Live-Patch im Speicher geladen ist. Auf einem frisch eingerichteten Server ist dies der normale Ausgangszustand.

Was Live Kernel Patching nicht beheben kann

Funktionskörper werden gepatcht. Alles andere nicht.

• Geänderte Datenstrukturen. Wenn der Upstream-Fix ein Feld zu einer Struktur hinzufügt oder die Bedeutung eines vorhandenen Felds ändert, gibt es keine sichere Möglichkeit, bereits allokierte und verwendete Objekte umzuschreiben. Das kpatch-Projekt beschreibt den entsprechenden Fall direkt: „Patches, die statisch allokierte Daten ändern, werden nicht direkt unterstützt.“ Shadow-Variablen und Callbacks dienen als Workaround. Sie werden jedoch für jeden Patch manuell geschrieben und nicht automatisch erzeugt.
• Fixes, die sich gleichzeitig über mehrere Funktionen erstrecken. Ein Fix, der die Reihenfolge von Sperren über eine Gruppe von Funktionen hinweg ändert, muss alle diese Funktionen gemeinsam ändern. Das Konsistenzmodell wechselt Tasks, statt den gesamten Rechner in einem einzigen Moment einzufrieren.
• Initialisierungscode. Funktionen, die mit __init markiert sind, wurden bereits ausgeführt und freigegeben, wenn Ihr Server läuft. Es gibt daher nichts mehr, was umgeleitet werden könnte.
• Neue Kernel-Versionen und neue Funktionen. Live Patching bewegt Sie innerhalb einer Kernel-Serie auf eine andere Patch-Stufe. Es wechselt niemals von einer Serie zur nächsten und fügt niemals eine Funktion hinzu. Wenn Sie etwas aus einer neueren Serie benötigen, beispielsweise die Änderungen aus Linux 7.1, installieren Sie diesen Kernel und booten ihn.
• Userspace. Canonical beschreibt die Grenze selbst: „Canonical Livepatch patcht keine Userspace-Bibliotheken wie OpenSSL oder glibc, weil dafür unattended-upgrades oder ein Systemverwaltungstool zuständig ist.“ Ein live gepatchter Kernel neben einem veralteten OpenSSL ist kein gepatchter Server. Lassen Sie daher unattended upgrades die Userspace-Pakete auf demselben Rechner verwalten.

Für den Dienst von Ubuntu gibt es außerdem eine Grenze beim Schweregrad. Canonical sagt, dass er „Kernel-Sicherheitslücken mit kritischen und hohen Bewertungen nach dem Common Vulnerability Scoring System (CVSS) und den Ubuntu-Prioritätsstufen patcht“. Ein CVE-Identifier (Common Vulnerabilities and Exposures) bezeichnet eine einzelne Schwachstelle. CVSS ist die zugehörige Bewertung. Eine Kernel-CVE mit mittlerem Schweregrad wird im Paket auf der Festplatte behoben und nicht live gepatcht. Sie erreicht Ihren laufenden Kernel daher erst beim nächsten Reboot und nicht früher.

Welche Optionen für Live-Kernel-Patching gibt es?

Drei Entwicklungslinien sind heute verbreitet. Sie greifen alle auf dieselbe Kernel-Infrastruktur zurück.

Canonical Livepatch wird über Ubuntu Pro bereitgestellt. Ubuntu Pro ist für die private Nutzung kostenlos. Canonical formuliert dies als „is and always will be free for personal use on up to 5 physical machines“ und erhöht das Limit für offizielle Ubuntu-Community-Mitglieder auf 50 Maschinen. Das ist der dokumentierte Stand von August 2026. Für die kommerzielle Nutzung ist ein kostenpflichtiges Abonnement erforderlich. Die Abdeckung wird pro Kernelserie und pro Variante gewährt. Sie umfasst die General-Availability-Kernel (GA-Kernel) der unterstützten Long-Term-Support-Versionen (LTS) sowie deren Hardware-Enablement-Kernel (HWE-Kernel). Unterstützte Varianten sind unter anderem generic, aws, azure, gcp, oracle, ibm und lowlatency. Prüfen Sie Ihren Kernel anhand der von Canonical veröffentlichten Kernel-Liste, bevor Sie sich darauf verlassen.

KernelCare von TuxCare ist ein kommerzieller Agent. Er unterstützt viele Distributionen, auch solche ohne eigenen Herstellerdienst. Die dokumentierte Installation verwendet das Hersteller-Skript curl -s -L https://kernelcare.com/installer | bash. Anschließend wird mit /usr/bin/kcarectl --register KEY eine schlüsselbasierte Lizenz eingerichtet. Der Agent sucht danach nach einem eigenen Zeitplan nach neuen Patches. /usr/bin/kcarectl --update erzwingt eine Prüfung. Lesen Sie das Installationsskript, bevor Sie es auf einem wichtigen Server an eine Shell weiterleiten.

kpatch und kGraft sind die Vorläufer. kGraft stammt von SUSE, kpatch von Red Hat. Der Live-Patching-Kern im heutigen Upstream-Linux ist aus der Zusammenführung beider Ansätze entstanden. kpatch selbst wird eingestellt: In der README steht, dass „the kpatch project is deprecated and in maintenance mode“ ab Linux 6.19 gilt. Im Upstream-Kernel wird kpatch-build durch klp-build ersetzt. Unter RHEL und dessen Rebuilds sollten Sie den eigenen Dienst der Distribution verwenden, statt Patches manuell zu erstellen.

Entscheiden Sie anhand dessen, was Ihre Distribution unterstützt und welche Lizenz Ihre Nutzung erlaubt. Das Ergebnis auf Kernel-Ebene ist in allen Fällen gleich.

So aktivieren Sie Canonical Livepatch unter Ubuntu

Rufen Sie zuerst in Ihrem Ubuntu-Pro-Konto ein Token ab. Beide folgenden Befehle benötigen funktionierenden ausgehenden Netzwerkzugriff, weil der Client mit den Servern von Canonical kommuniziert, um das System zu verknüpfen und Patches abzurufen.

sudo pro attach TOKEN
sudo pro status

Wenn Sie sudo pro attach ohne Token ausführen, startet stattdessen ein browserbasierter Ablauf und gibt einen Code aus, den Sie auf der Website von Canonical eingeben müssen. Beim Verknüpfen werden die empfohlenen Dienste automatisch aktiviert. Dazu gehört bei einer aktuellen LTS-Version auch Livepatch. Verwenden Sie sudo pro attach --no-auto-enable, wenn Sie die Dienste lieber selbst auswählen möchten.

Wenn Livepatch noch nicht aktiviert ist:

sudo pro enable livepatch
sudo canonical-livepatch status

Der Dienst läuft über den canonical-livepatch-Snap. Daher muss snapd funktionieren, damit die Aktivierung abgeschlossen werden kann. pro status gibt eine Tabelle mit den Diensten sowie deren Berechtigung und Status aus. canonical-livepatch status gibt die Details für den jeweiligen Kernel aus. Die Dokumentation von Canonical zeigt eine Ausgabe in dieser Form:

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

Zwei Zeilen enthalten die entscheidende Information. kernel state gibt an, ob die von Ihnen ausgeführte Kernel-Serie überhaupt vom Dienst abgedeckt wird. Diese Zeile zeigt einen Fehler, wenn Sie einen Kernel starten, den Livepatch nicht unterstützt. patch state gibt an, ob die für diesen Kernel verfügbaren Patches tatsächlich geladen sind. Ein abgedeckter Kernel, auf den keine Patches angewendet wurden, weist auf ein Client-Problem hin. Ein nicht abgedeckter Kernel ist ein Kernel-Problem. Keine Client-Einstellung kann dieses Problem beheben.

Wie erkenne ich, ob ein Neustart aussteht?

Live-Patching beseitigt den unmittelbaren Handlungsdruck. Dadurch ist ein ausstehender Neustart nicht mehr offensichtlich. Sie müssen gezielt danach suchen.

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

Der Paketmanager erstellt /var/run/reboot-required, wenn ein installiertes Paket einen Neustart benötigt, damit die Änderung wirksam wird. Ein neues linux-image-Paket erstellt diese Datei immer. Die Datei .pkgs listet die Pakete auf, die den Neustart angefordert haben. Gibt der erste Befehl No such file or directory aus, wurde seit dem letzten Systemstart kein Neustart angefordert. Bei aktuellen Ubuntu-Versionen ist /var/run ein symbolischer Link auf /run. Beide Pfade führen daher zur gleichen Datei.

Dieses Kennzeichen liegt in einem tmpfs und wird bei jedem Systemstart zurückgesetzt. Prüfen Sie es deshalb zusätzlich gegen den Kernel selbst:

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

uname -r gibt den aktuell ausgeführten Kernel aus. Der zweite Befehl gibt die auf dem Datenträger installierten Kernel-Pakete aus. Ein linux-image in dieser Liste, das neuer ist als die von uname -r gemeldete Version, bedeutet, dass das System mit einem alten Kernel läuft, unabhängig vom Status von Livepatch. Diese Prüfung ist entscheidend, weil Live-Patching den laufenden Kernel absichert, ihn aber nicht auf den aktuellen Stand bringt.

Für den Userspace-Teil derselben Prüfung ist needrestart standardmäßig auf Ubuntu Server installiert. Das Tool listet die laufenden Dienste auf, die noch gelöschte Bibliotheksdateien geöffnet halten.

sudo needrestart -r l

Das Flag-Paar -r l bedeutet „nur auflisten“. Der Befehl zeigt daher lediglich Informationen an und nimmt keine Änderungen vor.

Warum der Reboot nie verschwindet

Der Kernel auf dem Datenträger bleibt unverändert. Live-Patches werden in den laufenden Kernel geladen und nie in das Boot-Image geschrieben. Nach einem Reboot starten Sie daher mit dem Kernel, den linux-image der Bootloader auswählt. Anschließend wendet der Livepatch-Client die weiterhin passenden Patches erneut an. In der Zeit zwischen diesen beiden Vorgängen läuft nicht gepatchter Code. Das ist ein weiterer Grund, mit einem aktuellen Kernel statt mit einem alten zu booten.

Die Abdeckung gilt jeweils für eine Kernel-Serie. Serien werden aus dem Support genommen. Wenn Ihre laufende Serie nicht mehr in der Liste der unterstützten Serien enthalten ist, meldet die kernel state-Zeile keine Abdeckung mehr. Die einzige Lösung ist ein neuerer Kernel. Das erfordert einen Reboot.

Kernel-Korrekturen mit mittlerem oder niedrigem Schweregrad werden nie live gepatcht. Sie befinden sich im Paket auf dem Datenträger und werden erst beim Booten aktiv.

Bei lange laufenden Kerneln sammelt sich außerdem Zustand an, den das Patchen nicht bereinigt. Die Position von Canonical ist hier ein Zitat wert, weil sie die Sachlage ehrlich beschreibt: Livepatch „ist kein Ersatz für einen Reboot. Es ist ein Werkzeug, das Ihnen mehr Kontrolle gibt, indem es ungeplante Reboots verhindert.“ Das Wort, das dabei die Bedeutung trägt, ist ungeplant. Sie führen weiterhin Reboots durch. Sie entscheiden, wann.

Wie Sie einen Neustart planen, nach dem das System wieder startet

Ein VPS-Neustart ist einseitig, wenn Sie die Konsole nicht erreichen können. Bevor Sie reboot eingeben, stellen Sie sicher, dass Sie wieder Zugriff erhalten, falls die Maschine nicht zurückkommt.

• Vergewissern Sie sich, dass Ihr Anbieter in der Systemsteuerung eine serielle Konsole oder eine VNC-Ansicht (Virtual Network Computing) bereitstellt, und öffnen Sie sie jetzt statt während des Ausfalls.
• Prüfen Sie den freien Speicherplatz mit df -h /boot. Ein volles /boot führt dazu, dass das Kernelpaket beim Schreiben seines initramfs (initialen RAM-Dateisystems) fehlschlägt. Dadurch kann ein Bootloader-Eintrag auf ein Image verweisen, das nie vollständig erstellt wurde.
• Lassen Sie mindestens einen bekannten, funktionierenden älteren Kernel installiert. GRUB führt ihn unter "Advanced options for Ubuntu" auf. Das Starten dieses Kernels ist die schnellste Wiederherstellung, wenn ein neuer Kernel fehlschlägt.
• Ermitteln Sie den Rescue-Modus Ihres Anbieters, bevor Sie ihn benötigen. Wenn die Konsole nach dem Neustart eine initramfs-Eingabeaufforderung anzeigt, erfolgt die Reparatur dort.

Führen Sie den Neustart anschließend zu einem Zeitpunkt durch, zu dem Sie wach sind:

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

Damit wird der Neustart für fünf Minuten später geplant und eine Nachricht an angemeldete Benutzer gesendet. sudo shutdown -c bricht ihn ab. Wenn die Maschine wieder erreichbar ist, prüfen Sie beide Teile:

uname -r
sudo canonical-livepatch status

uname -r sollte nun den neueren Kernel melden. Die Statusausgabe sollte außerdem melden, dass die neue Serie abgedeckt ist. Wenn die Maschine überhaupt nicht zurückkommt, liegt der Fehler fast immer im Bootpfad und nicht im Netzwerk. Verwenden Sie dann den Wiederherstellungsweg aus der Anleitung zu einem VPS, der nach einem Kernelupdate nicht startet.

Warum alte Kernel weiterhin entfernt werden müssen

Live-Patching verschärft dieses Problem, statt es zu lösen, weil dadurch der Druck zum Neustart entfällt, während weiterhin linux-image-Pakete installiert werden. Jeder Kernel installiert ein Boot-Image, ein initramfs, einen Modulbaum und normalerweise ein Header-Paket. Auf einem kleinen VPS mit einer separaten /boot-Partition von wenigen hundert Megabytes füllen drei oder vier Kernel diese Partition.

Eine volle /boot verhindert anschließend die Installation des nächsten Kernels. Dadurch kann ein System genau das benötigte Update nicht mehr installieren. Der Pfad über apt autoremove entfernt alte Kernel, sobald sie dafür geeignet sind. Auf einem System, das nie neu gestartet wird, sind sie jedoch nicht immer geeignet, weil der Paketmanager keinen Kernel entfernt, den Sie möglicherweise noch ausführen.

Prüfen Sie daher, welche Kernel installiert sind. Behalten Sie den aktuell ausgeführten Kernel und einen bekannten funktionierenden Fallback. Entfernen Sie die übrigen Kernel gemäß dem sicheren Verfahren zum Entfernen alter Kernel unter Ubuntu. Entfernen Sie niemals den Kernel, den uname -r aktuell meldet.

FAQ

Bedeutet Live-Kernel-Patching, dass ich meinen VPS nie neu starten muss?

Nein. Live-Patches werden in den laufenden Kernel geladen, aber nicht in das Boot-Image geschrieben. Daher bleibt der linux-image auf dem Datenträger auf der Version, mit der Sie gebootet haben. Canonical formuliert es eindeutig: Livepatch „ist kein Ersatz für einen Neustart. Es ist ein Werkzeug, das Ihnen mehr Kontrolle gibt, indem es ungeplante Neustarts verhindert.“ Die Abdeckung endet außerdem, wenn Ihre Kernel-Serie eingestellt wird. Kernel-Korrekturen mittlerer Schwere werden grundsätzlich nicht per Livepatch eingespielt. Planen Sie stattdessen regelmäßige Wartungsneustarts nach einem von Ihnen festgelegten Zeitplan, statt auf einen erzwungenen Neustart zu warten.

Wie prüfe ich, ob das Live-Kernel-Patching tatsächlich Patches einspielt?

Führen Sie sudo canonical-livepatch status aus und lesen Sie zwei Zeilen. kernel state meldet, ob Ihre laufende Kernel-Serie durch den Dienst abgedeckt ist. patch state meldet, ob die Patches für diesen Kernel geladen sind. Sie können die Kernel-Seite außerdem direkt mit ls /sys/kernel/livepatch/ prüfen. Der Befehl listet für jeden geladenen Patch ein Verzeichnis auf. Eine leere Ausgabe bedeutet, dass derzeit kein Patch im Speicher aktiv ist, unabhängig davon, was der Client meldet.

Ist Ubuntu Pro auf einem persönlichen VPS kostenlos?

Ja, innerhalb eines dokumentierten Limits. Canonical formuliert es so: Ubuntu Pro „ist und bleibt für die persönliche Nutzung auf bis zu 5 physischen Maschinen kostenlos“. Für offizielle Mitglieder der Ubuntu Community steigt das Limit mit Stand August 2026 auf 50 Maschinen. Für die kommerzielle Nutzung ist ein kostenpflichtiges Abonnement erforderlich. Sie verknüpfen eine Maschine mit sudo pro attach TOKEN, wobei Sie ein Token von der Seite Ihres Ubuntu-Pro-Kontos verwenden. Anschließend aktivieren Sie den Dienst mit sudo pro enable livepatch.

Warum wird eine Kernel-CVE nach der Ausführung von Livepatch weiterhin als nicht behoben aufgeführt?

In der Regel gibt es dafür einen von zwei Gründen. Die Korrektur kann unterhalb des Schweregrads liegen, für den Livepatch eingesetzt wird. Canonical gibt an, dass Livepatch „Kernel-Schwachstellen mit kritischen und hohen Bewertungen nach dem Common Vulnerability Scoring System (CVSS) und den Ubuntu-Prioritätsstufen“ patcht und die übrigen Korrekturen dem Paket auf dem Datenträger überlässt. Oder die Korrektur lässt sich möglicherweise nicht als Änderung am Funktionsrumpf formulieren. Das ist beispielsweise der Fall, wenn der Upstream-Code eine Datenstruktur geändert hat. Eine solche Änderung kann Livepatch bei bereits angelegten Objekten nicht sicher durchführen. In beiden Fällen ist die Lösung identisch: Installieren Sie das aktualisierte Kernel-Paket und booten Sie den Server damit.

Was deckt Live-Kernel-Patching überhaupt nicht ab?

Userspace. Canonical stellt ausdrücklich fest, dass Livepatch „keine Userspace-Bibliotheken wie OpenSSL oder glibc patcht, weil dafür unattended-upgrades oder ein Systemverwaltungstool zuständig ist“. Außerdem kann Livepatch keine neue Kernel-Version und keine neue Funktion bereitstellen, da nur Funktionsrümpfe innerhalb der bereits ausgeführten Serie ersetzt werden. Ebenso können __init-Funktionen nicht gepatcht werden. Diese Funktionen wurden zu dem Zeitpunkt, an dem der Server bereit ist, bereits ausgeführt und aus dem Speicher freigegeben.