Ubuntu Kernel Livepatch

    Mich würden eure Erfahrungen mit Canonical Livepatch auf produktiven Ubuntu-Servern interessieren. Bisher habe ich bewusst darauf verzichtet, weil dafür snapd erforderlich ist und ich Snap auf Servern möglichst vermeiden wollte. Aus diesem Grund habe ich Kernel-Updates bisher klassisch eingespielt.

    Inzwischen sind zeitkritische Kernel-Sicherheitsupdates für mich jedoch wichtiger geworden. Mich interessieren daher vor allem praktische Erfahrungen:

    • Läuft Canonical Livepatch zuverlässig auf Produktivservern?
    • Gab es Probleme oder unerwartete Nebenwirkungen?
    • Gab es Probleme im Zusammenhang mit DKMS-Modulen oder anderen Kernel-Modulen nach der Verwendung von Livepatch?

  • Hille 8. Juli 2026 um 15:24

    Hat den Titel des Themas von „Ubuntu Livepatch“ zu „Ubuntu Kernel Livepatch“ geändert.

    Keine direkte Erfahrung, nur eine generelle Einschätzung: Falls Dir eine zeitnahe Behebung von Kernelbugs wichtig ist, auf jeden Fall von Ubuntu Abstand halten. Deren Strategie, neue Kernel nur alle paar Wochen zu releasen, auch bei kritischen Schwachstellen,, muss man mögen.

    Oder anders ausgedrückt: Wenn Dein Kernel sowieso drei Wochen nicht gepatched und verwundbar ist, dann ist's eigentlich auch egal ob er dann ge-live-patched wird oder Du nach 2 Tagen einen manuellen reboot machst... dann lieber ein Debian stable, Schwachstellen nach 2 Tagen gepatched und ein manueller oder geteiggerter reboot.

    Mir geht es in dem genannten Beispiel eher um die Zuverlässigkeit vom Canonical Kernel Livepatch. Ob man generell Debian oder Ubuntu einsetzen sollte, ist ja ein Thema, was gefühlt seit mehreren Jahrzehnten diskutiert wird. Es gibt Anwendungsfälle da würde ich sicher Debian den Vorzug geben, aber eben auch Ubuntu. In meinem Fall ist Ubuntu halt die sinnvollere Option gewesen.

    Wie gesagt, mich interessieren Erfahrungswerte mit Ubuntu Kernel Livepatch.

    Entschuldige, falls das falsch rüber gekommen ist. Ich wollte keine Grundsatzdiskussion zwischen Debian/Ubuntu vom Zaun brechen, sondern auf folgendes Bezug nehmen:

    Zitat von Hille

    Inzwischen sind zeitkritische Kernel-Sicherheitsupdates für mich jedoch wichtiger geworden

    Wenn Du bei Ubuntu bleiben musst und schnell Kernelpatches einpflegen willst, solltest Du Dir den Stockkernel selbst kompilieren . Mit dem Live-Patching kommen sicherheitskritische Updates erst 3-4 Wochen später.

    Ich weiß, Du willst hier was anderes hören (daher höre ich jetzt auch auf mit meinen Kommentaren), ich wollte nur loswerden, dass die Frage "Live-Patching oder nicht" bei sicherheitskritischen Anforderungen eigentlich irrelevant ist.

    Zitat von SiebenG

    Mit dem Live-Patching kommen sicherheitskritische Updates erst 3-4 Wochen später.

    Hast oder hattest du das Live Patching in Benutzung? Ich bin mir nicht ganz sicher, ob du das nicht mit dem „Klassischen“ Kernel Update verwechselt. Hier gab es tatsächlich Verspätung bei den letzten kritischen Kernel Bugs.

    Ich verwende kein Live-Patching. Ich bekomme eine Nachricht von unattended upgrades, sobald der Server neu gebootet werden möchte, und das erledige ich dann recht zeitnah.

    Soweit ich das Live-Patching verstanden habe ist der Vorteil nur, dass du nicht "sofort" neu booten musst und die Zeit vom Einspielen des neuen Kernels bis zum Reboot der Patch schon 'live" ist. Allerdings basieren die Live-Patches ja auf den debs, daher meine Aussage, dass das Live-Patching nicht so viel bringt, wenn das Ubuntu Kernel Team Wochen braucht, die Patches zu erstellen(*)

    Da ich dazu gerade keine gute Internetquelle gefunden habe, habe ich nochmal die KI meines Vertrauens befragt und die bestätigt, dass die Live-Patches zeitgleich mit den neuen Kernelpaketen oder kurz danach veröffentlicht werden.

    (*) Ich bin mir auch nicht ganz sicher, ob die Verzögerung immer durch das Kernel-Team entsteht, die offizielle Linie von Ubuntu ist ja nur alle 4 Wochen einen Kernel zu releasen, außer bei gaaaaaanz kritischen CVEs, da darf dann auch nach zwei Wochen ein Fix kommen (https://documentation.ubuntu.com/kernel/explana…elease-updates/). Ich hatte in den letzten Monaten bei den ganzen Bugs öfter mal aufs build-Datum geschaut und mir sah das so aus, dass im Moment ziemlich genau alle 4-6 Wochen ein neuer Kernel kommt. 2 Wochen habe ich noch nie gesehen.

    Zitat von Hille
    • Läuft Canonical Livepatch zuverlässig auf Produktivservern?
    • Gab es Probleme oder unerwartete Nebenwirkungen?
    • Gab es Probleme im Zusammenhang mit DKMS-Modulen oder anderen Kernel-Modulen nach der Verwendung von Livepatch?

    Ich verwende Livepatch seit einigen Jahren auf mehreren amd64-Hosts (Erfahrungen mit arm64-Hosts sammle ich gerade erst, hier dauerte die Einführung etwas länger) und kann obige Fragen mit ja, nein, nein (Einsatz von OpenZFS*-DKMS-Modulen auf allen Servern) beantworten.

    (Was ebenfalls länger dauerte, war übrigens die Klärung/Implementation, dass eine Livepatch-Lizenz für alle Ubuntu-Installationen, also inklusive aller Container auf dem Host, nutzbar ist. Das ist bspw. wichtig für die Build-Server hier.)

    Auch die von SiebenG genannte Verzögerung kann ich aus der Erinnerung nicht generell nachvollziehen; ich hatte dies einmal vor Jahren anhand eines Beispiels kontrolliert (auf einem Server, der zu diesem Zeitpunkt nicht zeitnah neu gestartet werden konnte), und da ging es entsprechend der Kritikalität wirklich zügig. Ansonsten würde der Einsatz von Livepatch – welcher bei einer entsprechenden Anzahl von Hosts ja kostenpflichtig wird und für mich einer der wenigen (und leider immer weniger werdenden) Gründe ist, bei Ubuntu zu bleiben – auch nicht viel Sinn machen. Die neuen Versionen von canonical-livepatch listen die verfügbaren Livepatches für installierte Kernel mit Zeitstempeln auf; allerdings habe ich diese historisch niemals archiviert (und obiges Beispiel/Log von einem Vereinsserver hier bei Netcup wurde durch eine Neuinstallation schon lange wieder restlos entfernt).


    * Bzgl. "OpenZFS": Das sind selbstgebaute Pakete aus dem Upstream-Repository, welche alle modifizierten ZFS-Pakete von Canonical (zwecks Vereinheitlichung auch über Betriebssystemgrenzen hinweg) ersetzen; andere DKMS-Module verwende ich nicht:

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    3 Mal editiert, zuletzt von m_ueberall (9. Juli 2026 um 08:52)