8 Live-Kernel-Patching mit KLP #

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.

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.

So aktivieren Sie SLE Live Patching auf dem System:

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

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

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

Weitere Informationen finden Sie unter man klp.

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.

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.

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.

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/.

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.