Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Navigation
Bezieht sich auf SUSE Linux Enterprise Server 12 SP5

22 Live-Patching des Linux-Kernels mithilfe von kGraft

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

Die Live-Patching-Technologie kGraft führt das Patching zur Laufzeit für den LinuxKernel aus, ohne den Kernel anhalten zu müssen. 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.

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

Der SLE Live Patching-Dienst wird zusätzlich zur normalen SUSE Linux Enterprise Server-Wartung erbracht. kGraft-Patches, die über SLE Live Patching verteilt werden, ergänzen die normalen SLES-Wartungsaktualisierungen. SLE Live Patching kann über herkömmliche Aktualisierungsstapel und -verfahren bereitgestellt werden.

Die Angaben in diesem Dokument gelten für die AMD64/Intel 64- und POWER-Architekturen. Sollten Sie eine andere Architektur nutzen, können die Verfahren von den hier beschriebenen abweichen.

22.1 Vorteile von kGraft

Das Live-Kernel-Patching mit kGraft eignet sich insbesondere als rasche Reaktion in Notfällen (wenn schwere Schwachstellen bekannt sind und sobald wie möglich behoben werden sollen oder wenn schwere Probleme mit der Systemstabilität vorliegen, für die eine Fehlerbehebung bekannt ist). In geplanten Aktualisierungen, bei denen die Zeit keine entscheidende Rolle spielt, kommt dieses Verfahren nicht zum Einsatz.

Typische Anwendungsfälle für kGraft 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 Dienste für viele Kunden erbringen.

Als Hauptvorteil von kGraft muss der Kernel unter keinen Umständen angehalten werden, nicht einmal für kurze Zeit.

Ein kGraft-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. kGraft ersetzt ganze Funktionen im Kernel, selbst wenn sie gerade ausgeführt werden. Ein aktualisiertes kGraft-Modul kann bei Bedarf einen vorhandenen Patch ersetzen.

Zudem ist kGraft schlank – es ist nur wenig Code erforderlich, da andere standardmäßige Linux-Technologien eingebunden werden.

22.2 Low-Level-Funktion von kGraft

kGraft führt das Patching über die ftrace-Infrastruktur aus. Im Folgenden wird die Implementierung auf der AMD64-/Intel-64-Architektur beschrieben.

Zum Patchen einer Kernel-Funktion benötigt kGraft 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 Aufrufers 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, gilt daher ein „Trampolinverfahren“ ähnlich RCU (Read-Copy-Update, Lesen-Kopieren-Aktualisieren), damit die einzelnen Userspace-Threads, Kernel-Threads und Kernel-Interrupts fortlaufend einheitliche „Weltsicht“ behalten. 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.

22.3 Installieren von kGraft-Patches

In diesem Abschnitt werden die Aktivierung der Live Patching-Erweiterung für SUSE Linux Enterprise sowie die Installation der kGraft-Patches beschrieben.

22.3.1 Aktivierung von SLE Live Patching

So aktivieren Sie SLE Live Patching auf dem System:

  1. Falls das SLES-System noch nicht registriert ist, holen Sie dies jetzt nach. Die Registrierung kann wahlweise während der Systeminstallation oder nachträglich mit dem YaST-Modul Produktregistrierung (yast2 registration) ausgeführt werden. Klicken Sie nach der Registrierung auf Ja. Die Liste der verfügbaren Online-Aktualisierungen wird angezeigt.

    Wenn das SLES-System bereits registriert, SLE Live Patching jedoch noch nicht aktiviert ist, öffnen Sie das YaST-Modul Produktregistrierung (yast2 registration) 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 12 und klicken Sie auf Weiter.

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

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

  5. Prüfen Sie die Installationszusammenfassung und die ausgewählten Schemata. Das Schema Live Patching muss zur Installation ausgewählt sein.

  6. Schließen Sie die Installation mit Akzeptieren ab. Hiermit werden die grundlegenden kGraft-Komponenten zusammen mit dem anfänglichen Live-Patch auf dem System installiert.

22.3.2 Aktualisieren des Systems

  1. SLE Live Patching-Aktualisierungen werden in einer Form verteilt, bei der die Patches mithilfe von standardmäßigen SLE-Aktualisierungsstapeln angewendet werden können. Der anfängliche Live-Patch kann mit zypper patch, mit der YaST-Online-Aktualisierung oder einem gleichwertigen Verfahren aktualisiert werden.

  2. Der Kernel wird bei der Installation des Pakets automatisch gepatcht. Die Aufrufe der alten Kernel-Funktionen werden jedoch 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. Dennoch gelten Prozesse im Ruhezustand, die die alten Kernel-Funktionen nicht nutzen, nicht als Sicherheitsrisiko. In der aktuellen Version von kGraft kann der nächste kGraft-Patch dennoch erst dann angewendet werden, wenn alle Prozesse die Kernel-Userspace-Grenze überschritten haben, sodass die gepatchten Funktionen aus dem vorherigen Patch nicht mehr genutzt werden.

    Der globale Patching-Status ist aus dem Flag in /sys/kernel/kgraft/in_progress ersichtlich. Der Wert 1 bedeutet, dass Prozesse im Ruhezustand vorliegen, die noch aufgeweckt werden müssen. (Der Patching-Vorgang ist also noch nicht abgeschlossen.) Der Wert 0 bedeutet, dass alle Prozesse ausschließlich die gepatchten Funktionen nutzen und dass der Patching-Vorgang abgeschlossen ist. Alternativ rufen Sie diese Angaben mit dem Befehl kgr status ab.

    Sie können das Flag auch für einzelne Prozesse ermitteln. Prüfen Sie jeweils die Zahl unter /proc/PROZESSNUMMER/kgr_in_progress für die betreffenden Prozesse. Der Wert 1 weist wiederum auf Prozesse im Ruhezustand hin, die noch aufgeweckt werden müssen. Alternativ rufen Sie die Liste der Prozesse im Ruhezustand mit dem Befehl kgr blocking ab.

22.4 Patch-Lebenszyklus

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

tux > zypper lifecycle

Product end of support
Codestream: SUSE Linux Enterprise Server 12             2024-10-31
SUSE Linux Enterprise Server 12 SP2                     n/a*

Extension end of support
SUSE Linux Enterprise Live Patching                     2017-10-31

Package end of support if different from product:
SUSEConnect                              Now, installed 0.2.41-18.1, update available 0.2.42-19.3.1
apache2-utils                            Now


*) See https://www.suse.com/lifecycle  for latest information

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.

22.5 Entfernen eines kGraft-Patches

So entfernen Sie einen kGraft-Patch:

  1. Entfernen Sie zunächst den Patch selbst mit Zypper:

    zypper rm kgraft-patch-3_12_32-25-default
  2. Booten Sie dann den Computer neu.

22.6 Hängengebliebene Kernel-Ausführungsthreads

Die Kernel-Threads müssen auf kGraft vorbereitet werden. Software von Drittanbietern ist unter Umständen nicht für die kGraft-Einführung bereit und die Kernel-Module dieser Software erzeugen ggf. Kernel-Ausführungsthreads. Diese Threads blockieren den Patching-Vorgang auf Dauer. Als Notmaßnahme bietet kGraft die Möglichkeit, den Patching-Prozess zwangsweise zu beenden, ohne abzuwarten, bis alle Ausführungsthreads den Sicherheitskontrollpunkt überschritten haben. Schreiben Sie hierzu den Wert 0 in /sys/kernel/kgraft/in_progress. Wenden Sie sich an den SUSE-Support, bevor Sie dieses Verfahren ausführen.

22.7 Das Werkzeug kgr

Verschiedene kGraft-Verwaltungsaufgaben lassen sich mit dem Werkzeug kgr vereinfachen. Verfügbare Befehle:

kgr status

Zeigt den Gesamtstatus des kGraft-Patching (ready oder in_progress).

kgr patches

Zeigt eine Liste der geladenen kGraft-Patches.

kgr blocking

Zeigt eine Liste der Prozesse, die das Beenden des kGraft-Patching verhindern. Standardmäßig werden nur die PIDs aufgeführt. Mit -v werden die Kommandozeilen ausgegeben (falls vorhanden). Mit einem weiteren Schalter -v werden auch Stapel-Traces angegeben.

Weitere Informationen finden Sie unter man kgr.

22.8 Umfang der kGraft-Technologie

kGraft beruht auf dem Ersetzen von Funktionen. Die Datenstruktur kann mit kGraft 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 kGraft 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 kGraft ist die Unterstützung für Drittanbieter-Module, die Kernel-Threads erzeugen, begrenzt.

22.9 Umfang von SLE Live Patching

SLE Live Patching umfasst Fehlerbehebungen für SUSE-Sicherheitsanfälligkeiten (Common Vulnerability Scoring System, CVSS) ab Stufe 7 sowie Fehlerbehebungen hinsichtlich der Systemstabilität oder Datenbeschädigung. 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 3.0 als Grundlage für die SUSE CVSS-Einstufung finden Sie unter https://www.first.org/cvss/.

22.10 Interaktion mit den Supportprozessen

Wenn Sie gemeinsam mit dem SUSE-Support bestimmte technische Probleme beheben, erhalten Sie ggf. einen sogenannten 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 kGraft-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