Kernel Live Patching mit kpatch: Sicherheitsupdates ohne Reboot einspielen

1. Warum überhaupt ohne Reboot patchen?

Ein Kernel Sicherheitsupdate wirkt klassisch erst nach einem Neustart, weil der laufende Kernel im Arbeitsspeicher unverändert weiterläuft, bis das System neu bootet und den aktualisierten Kernel lädt. Bei einem einzelnen Webserver hinter einem Load Balancer ist das meist unproblematisch, bei einem stark ausgelasteten Datenbank Primary, einem zustandsbehafteten Cache Cluster Knoten oder einem Server mit sehr langen Cronjobs kostet ein Reboot dagegen echte Zeit und erzeugt Koordinationsaufwand.

Kernel Live Patching setzt genau hier an: Ein kritischer Sicherheitsfix wird zur Laufzeit in den bereits laufenden Kernel eingespielt, ohne den Prozess Speicher zu verlieren oder aktive Netzwerkverbindungen zu unterbrechen. Der eigentliche Reboot, der neue Funktionen, größere strukturelle Änderungen oder eine neue Kernel Hauptversion mitbringt, bleibt trotzdem regelmäßig fällig und wird durch Live Patching nur zeitlich planbarer statt komplett ersetzt.

2. Wie kpatch technisch funktioniert

kpatch baut auf demselben ftrace Mechanismus auf, der auch für Kernel Tracing genutzt wird: Für eine gepatchte Funktion wird am Funktionseinsprungspunkt ein Sprungbefehl eingefügt, der den Aufruf zur neuen, korrigierten Funktionsversion umleitet, während der ursprüngliche Funktionscode im Speicher unverändert erhalten bleibt. Diese Technik heißt Function Redirect und funktioniert, weil der Kernel ohnehin bereits einen Mechanismus für ftrace Instrumentierung an nahezu jeder Funktion bereithält.

Der eigentliche Patch entsteht nicht von Hand, sondern wird mit kpatch-build aus zwei Versionen des Kernel Quellcodes generiert: dem Original und der gepatchten Variante. Das Werkzeug übersetzt beide Stände, vergleicht die entstandenen Objektdateien und extrahiert automatisch nur die tatsächlich veränderten Funktionen als ladbares Kernel Modul.

# kpatch Kernel Modul aus einem Source Patch bauen (vereinfachtes Beispiel)
kpatch-build -t vmlinux \
  --sourcedir /usr/src/kernels/$(uname -r) \
  cve-2026-xxxxx.patch

# Ergebnis: ein ladbares Kernel Modul
ls kpatch-*.ko

3. Die kpatch Werkzeugkette im Alltag

Im laufenden Betrieb reduziert sich die tägliche Arbeit meist auf drei Befehle: kpatch load lädt ein bereits gebautes Patch Modul in den laufenden Kernel, kpatch list zeigt alle aktuell aktiven Patches inklusive der jeweils betroffenen Funktionen, und kpatch unload entfernt einen Patch wieder, sofern keine andere Abhängigkeit dagegenspricht.

Für den dauerhaften Betrieb über einen Reboot hinaus sorgt der systemd Service kpatch.service, der beim Systemstart alle in /var/lib/kpatch hinterlegten Patches automatisch erneut lädt. Ohne diesen Schritt wäre jeder Live Patch nach einem klassischen Reboot wieder verschwunden, weil ein frisch gestarteter Kernel naturgemäß wieder im ungepatchten Ausgangszustand läuft.

# Patch Modul laden und dauerhaft für zukünftige Boots registrieren
sudo kpatch install kpatch-cve-2026-xxxxx.ko
sudo kpatch load /var/lib/kpatch/$(uname -r)/kpatch-cve-2026-xxxxx.ko

# Aktive Patches und betroffene Funktionen auflisten
sudo kpatch list

# Patch bei Bedarf wieder entfernen
sudo kpatch unload kpatch-cve-2026-xxxxx

4. Canonical Livepatch für Ubuntu Server

Canonical bietet für Ubuntu LTS Server einen eigenen, cloud gestützten Dienst namens Livepatch an, der fertig gebaute Patches automatisch über das Ubuntu Advantage beziehungsweise Ubuntu Pro Abonnement bezieht und im Hintergrund einspielt, ohne dass Administratoren selbst einen Patch mit kpatch-build erstellen müssen. Für eine begrenzte Anzahl an Maschinen ist der Dienst auch ohne kostenpflichtiges Abonnement nutzbar.

Die Aktivierung erfolgt über das Kommandozeilenwerkzeug canonical-livepatch, das einen einmaligen Aktivierungstoken vom Ubuntu One Konto benötigt und danach eigenständig neue Patches herunterlädt, sobald Canonical sie für die jeweils installierte Kernel Version veröffentlicht.

# Livepatch Client installieren und mit Token aktivieren
sudo snap install canonical-livepatch
sudo canonical-livepatch enable <TOKEN>

# Status und aktuell eingespielte Patches anzeigen
sudo canonical-livepatch status --verbose

5. Red Hat kpatch und SUSE kGraft im Vergleich

Red Hat integriert kpatch direkt in RHEL und bietet über den Red Hat Kernel Livepatch Service vorgefertigte Patches für ausgewählte, sicherheitsrelevante CVEs an, die sich über den regulären Paketmanager als kpatch-patch Paket einspielen lassen, sobald ein Red Hat Abonnement mit entsprechender Berechtigung vorliegt. Der Dienst deckt bewusst nur eine Teilmenge aller CVEs ab, priorisiert nach tatsächlichem Ausnutzungsrisiko.

SUSE verfolgt mit kGraft einen technisch verwandten, aber eigenständig implementierten Ansatz, der ebenfalls auf Function Redirect setzt, jedoch mit einem eigenen Konsistenzmodell arbeitet, um Übergänge zwischen alter und neuer Funktion sauber zu synchronisieren, während laufende Aufrufe der betroffenen Funktion noch aktiv sind.

# RHEL: verfügbare kpatch Patches für den laufenden Kernel anzeigen
sudo yum list available 'kpatch-patch*'

# Konkretes Patch Paket installieren
sudo yum install kpatch-patch-5_14_0-570

# Aktiven Patch Status prüfen
sudo kpatch list

6. Grenzen: Nicht jeder CVE ist live patchbar

Live Patching funktioniert zuverlässig für lokal begrenzte Funktionskorrekturen, etwa eine fehlerhafte Bereichsprüfung in einem Netzwerktreiber. Sobald ein Sicherheitsfix jedoch tief in Datenstrukturen eingreift, etwa eine neue Struktur Größe oder ein geändertes Lock Verhalten voraussetzt, das mit laufenden, bereits im alten Format vorliegenden Instanzen kollidiert, lässt sich der Patch nicht sicher als reiner Function Redirect umsetzen.

In solchen Fällen markiert kpatch-build den Build als fehlgeschlagen oder der Patch Anbieter liefert für den betreffenden CVE gar keinen Live Patch, sondern verweist explizit auf einen regulären Kernel Reboot. Live Patching ist deshalb eine Ergänzung zum regulären Patch Management, kein vollständiger Ersatz, und ein Reboot Fenster sollte trotz aktivem Live Patching Programm nie vollständig aus der Planung verschwinden.

7. Monitoring und Verifikation aktiver Patches

In einer gemischten Server Landschaft mit vielen Maschinen lohnt sich eine zentrale Erfassung, welcher Live Patch Stand auf welchem Host aktiv ist, da kpatch list nur lokal Auskunft gibt. Ein einfaches Monitoring Skript, das den Status regelmäßig ausliest und an ein zentrales Monitoring System meldet, verhindert, dass einzelne Server unbemerkt hinter dem eigentlich erwarteten Patch Stand zurückbleiben.

Zusätzlich zur reinen Statusabfrage empfiehlt sich ein Abgleich der laufenden Kernel Version über uname gegen die Liste bekannter, noch offener CVEs, denn kpatch list zeigt zwar an, welche Patches geladen sind, aber nicht automatisch, ob damit tatsächlich alle relevanten Sicherheitslücken der jeweiligen Kernel Version geschlossen sind.

# Einfache Prüfung für Monitoring Systeme: Anzahl aktiver Patches
kpatch list | grep -c '\[enabled\]'

# Kernel Version und Patch Level gemeinsam erfassen
echo "kernel=$(uname -r) patches=$(kpatch list | grep -c enabled)"

8. Integration in den regulären Patch Management Prozess

Live Patching sollte als zusätzliche, schnellere Reaktionsebene für kritische CVEs verstanden werden, nicht als Ersatz für den regulären Wartungszyklus. Ein sinnvoller Ablauf reagiert auf einen frisch veröffentlichten kritischen CVE zunächst mit einem Live Patch, sofern verfügbar, und plant den vollständigen Kernel Reboot mit dem regulären Update weiterhin im nächsten geplanten Wartungsfenster ein.

Wichtig ist außerdem die Dokumentation, welche Live Patches auf welchem Server aktiv sind, weil ein späterer regulärer Reboot mit dem vollständigen Kernel Update den Live Patch überflüssig macht und ihn automatisch ablöst. Ohne saubere Nachverfolgung entsteht sonst Unsicherheit darüber, ob ein Server nach einem Reboot tatsächlich denselben Sicherheitsstand hat wie vorher über Live Patching erreicht.

9. Praxisbeispiel: Einsatz im Magento Hosting Kontext

Auf einem MySQL Primary, der ein Magento Cluster mit mehreren Frontend Knoten versorgt, oder einem Redis Knoten, der Session und Cache Daten für viele parallele Checkout Prozesse hält, ist ein ungeplanter Reboot außerhalb eines Wartungsfensters besonders teuer, weil Failover Mechanismen selbst bei sauberem Design kurze Unterbrechungen verursachen können. Live Patching erlaubt es, auf einen kritischen Kernel CVE innerhalb von Minuten zu reagieren, ohne dieses Risiko einzugehen.

Für zustandslose Webserver hinter einem Load Balancer lohnt sich der zusätzliche Aufwand für Live Patching dagegen seltener, weil ein Rolling Reboot einzelner Knoten ohnehin ohne spürbare Downtime möglich ist. Der größte Nutzen von Live Patching liegt deshalb gezielt bei den wenigen, wirklich kritischen, schwer redundant auslegbaren Servern in der Infrastruktur.

10. Zusammenfassung

11. FAQ: Kernel Live Patching