Live-Kernel-Patching oder Reboot beim VPS?

Was Live-Kernel-Patching auf einem VPS leistet

Live-Kernel-Patching wendet Sicherheitskorrekturen am Kernel auf einem laufenden System an. Dafür ist kein Reboot erforderlich, und Verbindungen werden nicht getrennt. 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-Kernel-Patching geeignet ist, als auch, was es nicht leisten kann.

Es verschafft Zeit. Den Reboot ersetzt es nicht. Ein Server, der sechs Monate lang per Live-Kernel-Patching aktualisiert wurde, läuft weiterhin mit dem alten Kernel-Image auf der Festplatte. Außerdem befinden sich alle diese Korrekturen ausschließlich im Arbeitsspeicher.

Live-Kernel-Patching wird häufig als Funktion eines Managed-Tarifs angeboten. Auf einem nicht verwalteten System aktivieren Sie es selbst mit zwei Befehlen. 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 enthält 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 verwendete Kernel mit diesem Kern erstellt wurde. Ohne ihn kann kein Live-Patching-Dienst auf diesem Rechner Änderungen anwenden.

Die Umleitung verwendet ftrace, den Function Tracer des Kernels. Die meisten Kernel-Funktionen werden mit einer call-Anweisung direkt am Anfang der Funktion kompiliert, bevor Argumente oder Stack verändert wurden. ftrace verwendet diese Aufrufstelle als Hook. Wird ein Patch angewendet, 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 beschreibt es klar: „Live-Patching muss den Code normalerweise direkt am Anfang des Funktionseinstiegs umleiten, bevor die Funktionsparameter oder der Stack in irgendeiner Weise verändert wurden.“

Aus diesem Satz folgen zwei Konsequenzen. Beide sind später wichtig. Patchbar ist nur eine Funktion, die ftrace einbinden kann. Eine Funktion, die ohne diesen Aufruf am Einstieg kompiliert wurde, kann überhaupt nicht gepatcht werden. Die kleinste Patch-Einheit ist außerdem immer eine vollständige Funktion, niemals eine einzelne Zeile innerhalb einer Funktion.

Der schwierigere Teil ist der sichere Wechsel in einem laufenden System. Wenn alter Code beim Austauschen der Funktion noch auf dem Stack einer CPU ausgeführt wird, entsteht eine Mischung aus altem und neuem Verhalten. Upstream-Linux löst dies mit einem Konsistenzmodell pro Task. Die Kernel-Dokumentation beschreibt es als Hybrid: „Es verwendet die Konsistenz pro Task und die Umschaltung an der Syscall-Barriere von kGraft, kombiniert mit der Umschaltung anhand von Stack-Traces aus kpatch.“ Tasks wechseln einzeln zum neuen Code, sobald der Kernel nachweisen kann, dass sich der jeweilige Task derzeit nicht innerhalb einer gepatchten Funktion befindet. Solange nicht jeder Task gewechselt hat, befindet sich der Patch im Übergang.

Sie können das Ergebnis 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 das 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 Feldes ändert, gibt es keine sichere Möglichkeit, bereits allokierte und verwendete Objekte umzuschreiben. Das kpatch-Projekt beschreibt den entsprechenden Fall direkt: „Patches which modify statically allocated data are not directly supported.“ Shadow-Variablen und Callbacks dienen als Workaround, werden aber für jeden Patch manuell erstellt und nicht automatisch.
• 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 zwischen Tasks, anstatt den gesamten Rechner zu einem einzigen Zeitpunkt einzufrieren.
• Initialisierungscode. Funktionen, die mit __init markiert sind, wurden bereits ausgeführt und freigegeben, wenn Ihr Server läuft. Es gibt daher nichts mehr, auf das umgeleitet werden kann.
• 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 keine 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 does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool.“ Ein live gepatchter Kernel neben einem veralteten OpenSSL bedeutet nicht, dass der Server gepatcht ist. Sorgen Sie daher dafür, dass unattended upgrades die Userspace-Pakete auf demselben System verwaltet.

Für den Dienst von Ubuntu gibt es außerdem eine Grenze beim Schweregrad. Canonical sagt, dass er „kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings“ patcht. Eine CVE (Common Vulnerabilities and Exposures) bezeichnet eine einzelne Schwachstelle. CVSS ist die dafür vergebene Bewertung. Eine als medium eingestufte Kernel-CVE wird im Paket auf dem Datenträger behoben, aber nicht live gepatcht. Sie erreicht Ihren laufenden Kernel daher erst beim nächsten Reboot.

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

Drei Varianten sind heute verbreitet. Sie verwenden alle dieselbe Kernel-Infrastruktur.

Canonical Livepatch wird über Ubuntu Pro bereitgestellt. Ubuntu Pro ist für die private Nutzung kostenlos. Canonical formuliert dies so: Der Dienst „ist und bleibt für die private Nutzung auf bis zu 5 physischen Rechnern kostenlos“. Für offizielle Mitglieder der Ubuntu-Community erhöht sich das Limit auf 50 Rechner. Das ist der dokumentierte Stand von August 2026. Für die kommerzielle Nutzung ist ein kostenpflichtiges Abonnement erforderlich. Die Abdeckung wird pro Kernel-Serie und pro Variante gewährt. Sie umfasst die General-Availability-Kernel (GA) der unterstützten Long-Term-Support-Releases (LTS) sowie deren Hardware-Enablement-Kernel (HWE). Unterstützt werden Varianten wie 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 erfolgt über ein Anbieter-Skript, curl -s -L https://kernelcare.com/installer | bash, gefolgt von /usr/bin/kcarectl --register KEY für eine lizenzschlüsselbasierte Lizenz. Der Agent sucht anschließend 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 eine Zusammenführung beider Ansätze. kpatch wird selbst eingestellt: In der README steht, dass „das kpatch-Projekt ab Linux 6.19 veraltet ist und sich im Wartungsmodus befindet“. Dabei wird kpatch-build im Upstream-Kernel durch klp-build ersetzt. Auf RHEL und seinen Rebuilds sollten Sie den eigenen Dienst der Distribution verwenden, statt Patches manuell zu erstellen.

Entscheiden Sie anhand der Unterstützung Ihrer Distribution und der Bedingungen Ihrer Lizenz. Das Ergebnis auf Kernel-Ebene ist in allen Fällen gleich.

So aktivieren Sie Canonical Livepatch auf Ubuntu

Rufen Sie zuerst auf der Ubuntu-Pro-Kontoseite 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 Canonical-Website eingeben. Beim Verknüpfen werden die empfohlenen Dienste automatisch aktiviert. Bei einer aktuellen LTS-Version gehört Livepatch dazu. 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 diesem Format:

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 relevante Information. kernel state gibt an, ob die von Ihnen ausgeführte Serie überhaupt vom Dienst abgedeckt wird. Diese Zeile zeigt einen fehlerhaften Status, wenn Sie einen Kernel starten, den Livepatch nicht unterstützt. patch state gibt an, ob die für diesen Kernel geltenden Patches tatsächlich geladen wurden. Ein abgedeckter Kernel ohne angewendete Patches weist auf ein Clientproblem hin. Ein nicht abgedeckter Kernel weist auf ein Kernelproblem hin. Keine Clienteinstellung kann dies beheben.

Woran erkenne ich, ob ein Neustart aussteht?

Live-Patching beseitigt den unmittelbaren Handlungsdruck. Ein ausstehender Neustart ist dadurch 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 führt die Pakete auf, die den Neustart angefordert haben. Gibt der erste Befehl No such file or directory zurück, wurde seit dem letzten Systemstart kein Neustart angefordert. Unter aktuellen Ubuntu-Versionen ist /var/run ein Symlink auf /run. Beide Pfade verweisen daher auf dieselbe Datei.

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

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 Kernelpakete aus. Ist ein linux-image in dieser Liste neuer als die von uname -r gemeldete Version, läuft auf dem System ein alter Kernel. Das gilt unabhängig vom Status von Livepatch. Diese Prüfung ist entscheidend, weil Live-Patching den laufenden Kernel absichern soll, nicht ihn auf den aktuellen Stand bringen.

Für den Userspace-Teil derselben Prüfung ist needrestart unter Ubuntu Server standardmäßig installiert. Das Programm 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 nur Informationen an und ändert nichts.

Warum der Reboot unvermeidbar bleibt

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

Die Abdeckung gilt pro Kernel-Serie, und Serien werden aus dem Support genommen. Sobald Ihre laufende Serie aus der Liste der unterstützten Serien fällt, meldet die Zeile kernel state keine Abdeckung mehr. Die einzige Lösung ist dann ein neuerer Kernel. Dafür ist ein Reboot erforderlich. Bei einem LTS-Release erreicht Sie die neuere Serie normalerweise als Hardware-Enablement-Kernel, der in ein Point-Release wie 26.04.1 aufgenommen wurde. Der Ersatz liegt dann bereits im Archiv. Es fehlt nur noch ein von Ihnen geplanter Bootvorgang.

Kernel-Korrekturen mit mittlerem und niedrigem Schweregrad werden nie live gepatcht. Sie liegen im Paket auf dem Datenträger und werden erst aktiv, wenn Sie den Kernel booten.

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

So planen Sie einen Reboot, nach dem der Server wieder startet

Ein VPS-Reboot 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.

• Bestätigen Sie, dass Ihr Provider im Control Panel eine serielle Konsole oder eine VNC-Ansicht (Virtual Network Computing) bereitstellt, und öffnen Sie sie jetzt statt erst während des Ausfalls.
• Prüfen Sie den freien Speicherplatz mit df -h /boot. Ein volles /boot führt dazu, dass das Kernel-Paket beim Schreiben seines initramfs (initiales RAM-Dateisystem) 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 listet ihn unter "Advanced options for Ubuntu" auf. Das Booten dieses Kernels ist die schnellste Wiederherstellung, wenn ein neuer Kernel fehlschlägt.
• Ermitteln Sie den Rescue-Modus Ihres Providers, bevor Sie ihn benötigen. Wenn die Konsole nach dem Reboot eine initramfs-Eingabeaufforderung anzeigt, führen Sie die Reparatur dort durch.

Starten Sie den Reboot anschließend zu einem Zeitpunkt, an dem Sie wach sind:

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

Damit wird der Reboot 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 jetzt 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 Kernel-Update nicht bootet.

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.

Ein volles /boot verhindert anschließend die Installation des nächsten Kernels. Dadurch kann ein System ausgerechnet das benötigte Update nicht mehr installieren. Der Pfad über apt autoremove entfernt alte Kernel, sobald sie dafür infrage kommen. Auf einem System, das nie neu startet, ist das jedoch nicht immer der Fall. Der Paketmanager entfernt keinen Kernel, den Sie möglicherweise noch verwenden.

Prüfen Sie daher, welche Kernel installiert sind. Behalten Sie den aktuell laufenden Kernel und einen bekannten funktionierenden Fallback. Entfernen Sie die übrigen Kernel mit 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 und nicht in das Boot-Image geschrieben. Daher bleibt der linux-image auf der Festplatte bei 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 live gepatcht. Planen Sie stattdessen in einem von Ihnen festgelegten Rhythmus einen Wartungsneustart, statt auf einen erzwungenen Neustart zu warten.

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

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 angewendet 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 Rechnern kostenlos“. Für offizielle Mitglieder der Ubuntu Community steigt das Limit mit Stand August 2026 auf 50 Rechner. Für die kommerzielle Nutzung ist ein kostenpflichtiges Abonnement erforderlich. Sie verknüpfen einen Rechner mit sudo pro attach TOKEN und einem Token aus Ihrer Ubuntu-Pro-Kontoseite. 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. Der Fix kann unterhalb des Schweregrads liegen, für den Livepatch vorgesehen ist. Canonical patched „Kernel-Schwachstellen mit kritischer und hoher Einstufung nach dem Common Vulnerability Scoring System (CVSS) und den Ubuntu-Prioritätsbewertungen“ live und überlässt die übrigen Korrekturen dem Paket auf der Festplatte. Oder der Fix lässt sich möglicherweise nicht als Änderung am Funktionsrumpf umsetzen. Das ist beispielsweise der Fall, wenn der Upstream eine Datenstruktur geändert hat. Eine solche Änderung kann Livepatch bei bereits angelegten Objekten nicht sicher durchführen. Beide Fälle werden auf dieselbe Weise behoben: Installieren Sie das aktualisierte Kernel-Paket und booten Sie diesen Kernel.

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

Userspace. Canonical stellt ausdrücklich fest, dass Livepatch „keine Userspace-Bibliotheken wie OpenSSL oder glibc patched, weil dafür unattended-upgrades oder ein Systemverwaltungstool zuständig ist“. Außerdem kann Livepatch weder eine neue Kernel-Version noch ein neues Feature bereitstellen. Der Dienst ersetzt nur Funktionsrümpfe innerhalb der Serie, die Sie bereits ausführen. Auch __init-Funktionen können nicht gepatcht werden. Diese wurden zu dem Zeitpunkt, an dem der Server verfügbar ist, bereits ausgeführt und aus dem Speicher freigegeben.