Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Desktop 15 SP2

8 Live-Kernel-Patching mit KLP Edit source

In diesem Dokument werden die Grundlagen der Kernel Live Patching-Technologie (KLP) erläutert und Sie finden hier Richtlinien für den SLE Live Patching-Dienst.

KLP ist eine Live Patching-Technologie für ein Patching zur Laufzeit für den Linux-Kernel ohne Anhalten des Kernels. So erzielen Sie die maximale Betriebszeit (und damit die maximale Verfügbarkeit) des Systems, was insbesondere bei unternehmenswichtigen Systemen von Bedeutung ist. Durch das dynamische Patching des Kernels können Benutzer auch kritische Sicherheitsaktualisierungen installieren, ohne bis zu einer geplanten Ausfallzeit warten zu müssen.

Zur Aktivieren von KLP sind keine speziellen Schritte erforderlich. Sie brauchen nur den Live Patching-Dienst zu aktivieren und dann die Patches nach Verfügbarkeit anzuwenden. Der Dienst ist Teil des normalen Softwareverwaltungssystems und Patches werden mit den üblichen Paketverwaltungstools installiert (oder entfernt). Es brauchen keine speziellen Kernel installiert oder manuell ausgewählt zu werden.

Ein KLP-Patch ist ein Kernel-Modul, das ganze Funktionen im Kernel ersetzt. Kernel Live Patching bietet hauptsächlich eine Kernel-interne Infrastruktur für die Integration des gepatchten Codes mit dem Kernel-Basiscode zur Laufzeit.

Die Angaben in diesem Dokument gelten für die AMD64/Intel 64- und POWER-Architekturen. KLP wird auf dem Xen-Hypervisor unterstützt.

8.1 Vorteile des Kernel Live Patching Edit source

Kernel Live Patching über KLP dient zur schnellen Reaktion auf Notfälle, wenn schwerwiegende Probleme mit Schwachstellen oder der Systemstabilität bekannt sind und so schnell wie möglich behoben werden sollten. In geplanten Aktualisierungen, bei denen die Zeit keine entscheidende Rolle spielt, kommt dieses Verfahren nicht zum Einsatz.

Typische Anwendungsfälle für Kernel Live Patching sind beispielsweise Speicherdatenbanken mit enormen Mengen an Arbeitsspeicher, bei denen eine Bootdauer von 15 Minuten oder länger nicht ungewöhnlich ist, umfangreiche Simulationen, die mehrere Wochen oder Monate ohne Neustart ausgeführt werden müssen, oder Infrastrukturbausteine, die ununterbrochene Services für viele Kunden erbringen.

Der Hauptvorteil von Kernel Live Patching besteht darin, dass dafür der Kernel niemals angehalten werden muss, nicht einmal für kurze Zeit.

Ein KLP-Patch ist ein .ko-Kernel-Modul in einem RPM-Paket. Der Patch wird mit dem Befehl insmod in den Kernel eingefügt, sobald das Paket installiert oder aktualisiert wird. Kernel Live Patching ersetzt ganze Funktionen im Kernel, selbst wenn sie gerade ausgeführt werden. Ein aktualisiertes KLP-Modul kann bei Bedarf einen vorhandenen Patch ersetzen.

Zudem ist Kernel Live Patching schlank und enthält nur wenig Code, da andere standardmäßige Linux-Technologien genutzt werden.

8.2 Low-Level-Funktion von Kernel Live Patching Edit source

Kernel Live Patching verwendet zum Patching die ftrace-Infrastruktur. Im Folgenden wird die Implementierung auf der AMD64-/Intel-64-Architektur beschrieben.

Zum Patchen einer Kernel-Funktion benötigt Kernel Live Patching etwas Platz am Anfang der Funktion, damit ein Sprung zu einer neuen Funktion eingefügt werden kann. Dieser Platz wird bei der Kernel-Kompilierung durch GCC mit aktivierter Funktionsprofilerstellung zugewiesen. Insbesondere wird eine 5 Byte umfassende Aufrufanweisung an den Anfang der Kernel-Funktionen eingebracht. Beim Booten eines derart ausgerüsteten Kernels werden die Profilerstellungsaufrufe durch 5-Byte-Nulloperationsanweisungen (NOP-Anweisungen) ersetzt.

Zu Beginn des Patching-Vorgangs wird das erste Byte durch die INT3-(Haltepunkt-)Anweisung ersetzt. So wird die Atomarität des 5-Byte-Anweisungsersatzes sichergestellt. Die weiteren vier Byte werden durch die Adresse zur neuen Funktion ersetzt. Schließlich wird das erste Byte durch den JMP-Opcode (Long Jump) ersetzt.

Mithilfe von IPI-NMIs (Inter-Processor Non-Maskable Interrupts) werden spekulative Decodierungswarteschlangen anderer CPUs im System entleert. So kann die Umstellung auf die neue Funktion erfolgen, ohne den Kernel anhalten zu müssen, nicht einmal für äußerst kurze Zeit. Die Unterbrechungen durch die IPI-NMIs messen sich nach Millisekunden und gelten nicht als Systemunterbrechungen, da der Kernel trotz dieser Unterbrechungen weiterläuft.

Aufrufer werden nicht gepatcht. Stattdessen werden die NOPs des Aufgerufenen durch ein JMP zur neuen Funktion ersetzt. JMP-Anweisungen bleiben dauerhaft erhalten. Hierdurch sind die Funktionszeiger gesichert (auch in Strukturen) und alte Daten müssen nicht für den Fall aufgehoben werden, dass der Patch rückgängig gemacht wird.

Diese Schritte allein würden allerdings nicht ausreichen: Die Funktionen werden nichtatomar ausgetauscht; eine neue, fehlerfreie Funktion in einem Teil des Kernels könnte dennoch eine alte Funktion an anderer Stelle aufrufen oder umgekehrt. Wenn die Semantik der Funktionsschnittstellen im Patch geändert würde, wäre Chaos unvermeidbar.

Bis alle Funktionen ersetzt sind, wendet Kernel Live Patching eine Art Trampolinverfahren an, ähnlich RCU (Read-Copy-Update, Lesen-Kopieren-Aktualisieren), damit die einzelnen Benutzerbereich-Threads, Kernel-Threads und Kernel-Interrupts konsistent auf dem gleichen Stand bleiben. Bei jedem Kernel-Ein- und -Ausstieg wird ein threadspezifisches Flag gesetzt. So ist gewährleistet, dass eine alte Funktion stets eine andere alte Funktion aufruft und eine neue Funktion stets eine neue. Sobald für alle Prozesse das Flag für das „neue Universum“ gesetzt ist, ist das Patching abgeschlossen, die Trampoline können abgebaut werden und der Code kann mit voller Geschwindigkeit und ohne Leistungseinbußen laufen, abgesehen von einem extrem langen Sprung bei den einzelnen gepatchten Funktionen.

8.3 Aktivierung von SLE Live Patching Edit source

So aktivieren Sie SLE Live Patching auf dem System:

  1. Ihr SLES-System muss registriert sein. Registrieren Sie Ihr System entweder bei der Systeminstallation oder nach der Installation mit dem YaST-Modul zur Produktregistrierung (yast2 registration). Wenn das SLES-System bereits registriert, SLE Live Patching jedoch noch nicht aktiviert ist, führen Sie das Kommando yast2 registration aus und klicken Sie auf Erweiterungen auswählen.

  2. Wählen Sie in der Liste der verfügbaren Erweiterungen den Eintrag SUSE Linux Enterprise Live Patching 15 und klicken Sie auf Weiter.

  3. Bestätigen Sie die Lizenzvereinbarung und klicken Sie auf Weiter.

  4. Geben Sie Ihren Registrierungscode für SLE Live Patching ein und klicken Sie auf Weiter.

  5. Prüfen Sie die Installationszusammenfassung und die ausgewählten Schemata. Die Schemata Live Patching und SLE Live Patching Lifecycle Data sollten automatisch zur Installation ausgewählt werden. Es sind zudem womöglich weitere Pakete vorhanden, die Abhängigkeiten berücksichtigen.

  6. Schließen Sie die Installation mit Akzeptieren ab. Dadurch werden die Basiskomponenten von Kernel Live Patching auf Ihrem System installiert sowie der ursprüngliche Live-Patch und alle Abhängigkeiten.

8.4 Installieren und Entfernen von Patches Edit source

In diesem Abschnitt wird beschrieben, wie Sie KLP-Patches suchen, installieren und entfernen.

8.4.1 Installieren eines KLP-Patchs Edit source

  1. Führen Sie vor der Installation neuer Patches das Kommando klp status aus, um den aktuellen Status abzufragen. Dieser muss ready und nicht in_progress lauten. Neue Patches können erst angewendet werden, nachdem die Installation von früheren Patches abgeschlossen ist. Die Aufrufe der alten Kernel-Funktionen werden erst dann vollständig beseitigt, wenn alle Prozesse aus dem Ruhezustand aufgeweckt wurden und der Aktualisierung nicht mehr im Wege stehen. Dies kann sehr lange dauern. Prozesse im Ruhezustand, die die alten Kernel-Funktionen nicht nutzen, gelten nicht als Sicherheitsrisiko. (In Abschnitt 8.6, „Hängengebliebene Kernel-Ausführungsthreads“ finden Sie Informationen zur Verwaltung von verlängerten in_progress-Zuständen.)

  2. Verwenden Sie zur Anzeige und Installation der verfügbaren Patches das normale Paketverwaltungssystem wie zypper oder YaST. Im folgenden Beispiel werden verfügbare Patches gesucht. Danach wird der neueste Patch installiert. Es ist nicht notwendig, alle Patches der Reihe nach zu installieren. Wenn mehrere Patches verfügbar sind, installieren Sie den neuesten Patch.

    tux > sudo zypper se kernel-livepatch 
    | kernel-livepatch-5_3_18-8_16-default  | Kernel live patch module  | package   
    | kernel-livepatch-5_3_18-8_19-default  | Kernel live patch module  | package   
    | kernel-livepatch-5_3_18-8_22-default  | Kernel live patch module  | package
    
    tux > sudo zypper in kernel-livepatch-5_3_18-8_22-default

8.4.2 Entfernen eines KLP-Patchs Edit source

Wenn Sie einen KLP-Patch entfernen müssen, verwenden Sie dazu zypper wie für jedes andere Paket. Listen Sie die installierten Live-Patch-Pakete mit zypper auf, um nach kernel-livepatch zu suchen:

tux > sudo zypper se -kernel-livepatch 
  | kernel-livepatch-5_3_18-8_16-default  | Kernel live patch module  | package   
  | kernel-livepatch-5_3_18-8_19-default  | Kernel live patch module  | package   
i | kernel-livepatch-5_3_18-8_22-default  | Kernel live patch module  | package
  1. Entfernen Sie den Patch mit zypper:

    tux > sudo zypper rm kernel-livepatch-5_3_18-8_22-default
  2. Warten Sie, bis initrd automatisch neu erstellt ist und booten Sie dann den Rechner neu.

8.5 Das Tool klp Edit source

Einige Kernel Live Patching-Verwaltungsaufgaben können mit dem Tool klp vereinfacht werden. Verfügbare Befehle:

klp status

Zeigt den Gesamtstatus von Kernel Live Patching (ready oder in_progress).

klp patches

Zeigt eine Liste der geladenen KLP-Patches.

klp blocking

Zeigt eine Liste der Prozesse, die das Beenden von Kernel Live Patching verhindern. Standardmäßig werden nur die PIDs aufgeführt. Mit -v werden die Kommandozeilen ausgegeben (falls vorhanden). Mit -vv werden Stapelüberprüfungen angezeigt.

Weitere Informationen finden Sie unter man klp.

8.6 Hängengebliebene Kernel-Ausführungsthreads Edit source

Kernel-Threads müssen für die Verarbeitung von Kernel Live Patching vorbereitet werden. Drittanbieter-Software unterstützt möglicherweise Kernel Live Patching nicht und erstellt Kernel-Ausführungsthreads. Diese Threads blockieren den Patching-Vorgang auf Dauer. Als Notfallmaßnahme können Sie die Fertigstellung des Patching-Vorgangs erzwingen, ohne darauf zu warten, dass alle Ausführungsthreads den Sicherheitsprüfpunkt überschritten haben. Schreiben Sie dazu 0 in /sys/kernel/livepatch/*/transition/ (und ersetzen Sie den Sternplatzhalter durch Ihren Dateinamen). Wenden Sie sich an den SUSE-Support, bevor Sie dieses Verfahren ausführen.

8.7 Patch-Lebenszyklus Edit source

Mit zypper lifecycle rufen Sie das Ablaufdatum der Live-Patches ab. (Prüfen Sie, ob das Paket lifecycle-data-sle-module-live-patching installiert ist.)

Sobald das Ablaufdatum eines Patches erreicht ist, werden keine weiteren Live-Patches für diese Kernelversion mehr bereitgestellt. Planen Sie die Aktualisierung des Kernels rechtzeitig vor dem Ende des Live-Patch-Lebenszyklus ein.

Details zum Zypper-Lebenszyklus finden Sie im Abschnitt Anzeigen von Informationen zum Lebenszyklus im Verwaltungshandbuch.

8.8 Umfang der Kernel Live Patching-Technologie Edit source

Kernel Live Patching basiert auf dem Ersatz von Funktionen. Die Datenstruktur kann mit Kernel Live Patching nur indirekt geändert werden. Änderungen an der Kernel-Datenstruktur verlangen daher besondere Vorsicht; bei zu großen Änderungen muss das System ggf. neu gebootet werden. Außerdem kann Kernel Live Patching unter Umständen nicht mit Situationen umgehen, in denen der alte Kernel von einem Compiler kompiliert wird und der neue Patch von einem zweiten Compiler.

Aufgrund der Funktionsweise von Kernel Live Patching ist die Unterstützung für Drittanbieter-Module, die Kernel-Threads erzeugen, begrenzt.

8.9 Umfang von SLE Live Patching Edit source

Die Fehlerbehebungen für Schwachstellen ab SUSE CVSS-Stufe 7 (Common Vulnerability Scoring System; SUSE CVSS beruht auf dem CVSS-3.0-System) sowie Fehlerkorrekturen im Zusammenhang mit der Systemstabilität oder mit Datenbeschädigung werden im Rahmen von SLE Live Patching bereitgestellt. Unter Umständen kann nicht für alle Fehlerbehebungen, die die obigen Kriterien erfüllen, ein Live-Patch bereitgestellt werden. SUSE behält sich das Recht vor, Fehlerbehebungen zu überspringen, wenn die Erzeugung eines Kernel-Live-Patches aus technischen Gründen nicht praktikabel ist. Weitere Informationen zu CVSS als Grundlage für die SUSE CVSS-Einstufung finden Sie unter https://www.first.org/cvss/.

8.10 Interaktion mit den Supportprozessen Edit source

Wenn Sie gemeinsam mit dem SUSE-Support bestimmte technische Probleme beheben, erhalten Sie ggf. einen PTF (Program Temporary Fix, temporäre Programm-Fehlerbehebung). PTFs können für verschiedene Pakete ausgegeben werden, z. B. für Pakete, die die Grundlage von SLE Live Patching bilden.

Die Kernel Live Patching-PTFs, die die Bedingungen im vorherigen Abschnitt erfüllen, können wie gewohnt installiert werden. SUSE sorgt dabei dafür, dass das betreffende System nicht neu gebootet werden muss und dass künftige Live-Aktualisierungen problemlos angewendet werden können.

PTFs für den Basis-Kernel unterbrechen den Live-Patching-Vorgang. Erstens: Wenn Sie den PTF-Kernel installieren, müssen Sie das System neu booten, da der Kernel als Ganzes nicht zur Laufzeit ersetzt werden kann. Zweitens: Ein zweiter Neustart ist erforderlich, damit der PTF durch normale Wartungsaktualisierungen ersetzt wird, für die die Live-Patches ausgegeben werden.

PTFs für andere Pakete in SLE Live Patching können wie reguläre PTFs mit den üblichen Zusicherungen behandelt werden.

Diese Seite drucken