Über unsMediaKontaktImpressum
Hannes Kühnemund 28. Juni 2016

Live-Patching: Ausfallzeiten runter – Security hoch

Wenn der planmäßige oder unplanmäßige Ausfall von Diensten in Unternehmen zu Unterbrechungen des Betriebsablaufs führt, verlieren immer alle: Das Unternehmen verliert Zeit und Geld und der Anbieter der Dienste verliert seinen guten Ruf. Ob ein Server aufgrund einer geplanten Wartung oder wegen eines Defekts nicht mehr erreicht werden kann, ist dabei zumeist unerheblich – Unterbrechungen kosten auch dann Geld, wenn sie im Vorfeld angekündigt wurden.

Es lohnt sich also, sich genauer mit diesem Thema auseinanderzusetzen. Nachfolgend soll zunächst ein Blick auf die unterschiedlichen Gründe für Ausfallzeiten geworfen werden. Anschließend geht es um technische Möglichkeiten, Ausfallzeiten zu verringern. Dass hierbei die Systemsicherheit stets gewahrt bleiben muss, versteht sich von selbst. Ausfallzeiten existieren in zwei unterschiedlichen Formen – entweder als geplante oder als ungeplante Ausfallzeiten.

Geplante Ausfallzeiten

Geplante Ausfallzeiten treten normalerweise im Rahmen festgelegter Wartungsfenster auf. Damit die Wartung die Betriebsabläufe eines Unternehmens möglichst wenig beeinträchtigt, müssen bei der terminlichen Gestaltung der dafür vorgesehenen Zeitfenster die Bedürfnisse verschiedenster Stakeholder beachtet werden. Üblicherweise fallen sie auf ein Wochenende, da der Abstimmungsbedarf auf diese Weise minimiert werden kann. Die Häufigkeit hängt von verschiedenen Faktoren ab und bewegt sich, je nach Unternehmen, üblicherweise zwischen monatlicher und jährlicher Wartung. Innerhalb der Zeitfenster werden administrative Tätigkeiten an der Software, der Hardware oder am Rechenzentrum selbst durchgeführt.

Im Software-Bereich sind Ausfallzeiten durch Änderungen an der System- oder Anwendungskonfiguration, häufig aber durch Software-Updates bedingt. Im letzteren Fall geht es darum, durch die Einspielung neuer Software-Pakete zusätzliche Funktionalitäten bereitzustellen und fehlerhafte Software zu eliminieren oder zu reparieren. Die Eliminierung von Softwarefehlern hat unter Umständen einen rechtlichen Hintergrund, zum Beispiel wenn man Kreditkarteninformationen verarbeitet und den PCI-Sicherheitsstandards unterworfen ist.

Im Hardware-Bereich trifft man im Wartungszusammenhang oft auf das Schlagwort "Mean Time Between Failures" (MTBF), welches dem Administrator suggeriert, er könne unter Zuziehung stochastischer Methoden berechnen, wann eine bestimmte Hardware-Komponente ausfällt. In einigen Bereichen mag ein solches Vorgehen hilfreich sein, verlassen kann man sich darauf jedoch nicht. Deshalb wird das Wartungsfenster im Hardware-Bereich dazu genutzt, defekte Komponenten wie Festplatten, CPUs oder Speicher auszutauschen. Ausgetauscht wird mitunter auch Hardware, die zwar noch nicht kaputt ist, aber über das Systemlog einen baldigen Ausfall ankündigt. Auch der vollständige Austausch eines geschlossenen Systems, wie zum Beispiel einer Storage-Einheit, kann im Wartungsfenster erfolgen.

Natürlich bieten sich Wartungsfenster auch an, um Arbeiten an der Infrastruktur oder am Rechenzentrum selbst vorzunehmen. Dazu fallen unter anderem Arbeiten an der Netzwerkinfrastruktur, die Reinigung der Klimaanlage, eine Überprüfung der Feuerlöschanlage oder generelle Reparaturarbeiten am Gebäude.

Für Unternehmen mit einem eigenen Rechenzentrum ist es nicht möglich, geplante Ausfallzeiten im Rahmen von Wartungsfenstern zu vermeiden. Lediglich Frequenz und Dauer lassen sich minimieren. Ein Weg sind Lösungen wie SUSE Manager auf Ebene des Betriebssystems oder SAP Landscape Virtualization Management für die SAP-Landschaft, die eingesetzt werden können, um Tätigkeiten zu automatisieren oder zu parallelisieren. Folgendes Dilemma lässt sich damit jedoch nicht ausräumen: Während einige Wartungsarbeiten nur sehr selten durchgeführt werden müssen, ist es besonders im Hinblick auf Sicherheitsaspekte unumgänglich, mit hoher Regelmäßigkeit Aktualisierungen an der Infrastruktur des Rechenzentrums vorzunehmen. Das Problem verschwindet auch dann nicht, wenn man ausschließlich auf Hosting oder die Public Cloud setzt. In einem solchen Fall hat man die Wartung lediglich an den Dienstleister ausgelagert – der Cloud- oder Hosting-Anbieter übernimmt diese Aufgaben dann, aber die Ausfallzeiten verschwinden dadurch nicht. Über entsprechende Service-Level-Agreements können geplante Ausfallzeiten allenfalls minimiert, nicht aber vollständig vermieden werden.

Ungeplante Ausfallzeiten

Wie der Name schon sagt, sind ungeplante Ausfallzeiten schlicht nicht vorherzusehen. Ihr Auftreten folgt Murphys berühmten Gesetz: Zu ungeplanten Ausfällen kommt es zumeist dann, wenn der Zeitpunkt schlechter kaum sein könnte. Glücklicherweise existiert inzwischen für fast jedes mögliche Szenario mindestens eine Technologie, die im Ernstfall Abhilfe schafft.

Zu ungeplanten Ausfällen kommt es zumeist dann, wenn der Zeitpunkt schlechter kaum sein könnte.

Einige Beispiele: Gegen Stromausfälle helfen neben einer redundanten Stromversorgung auch Batterieschränke und Dieselgeneratoren. Kommt es zu Festplattenausfällen, stellen RAID-Systeme die Datenverfügbarkeit sicher – die defekten Festplatten können bequem im Rahmen eines Wartungsfensters ausgetauscht werden. Load-Balancer, sofern von der Anwendung unterstützt, erlauben den fortlaufenden Betrieb eines Systems, selbst wenn eine oder mehrere Komponenten ausfallen. RAS-Features (Reliability, Availability, Serviceability) melden dem Betriebssystem fehlerhafte CPUs und Arbeitsspeichermodule; diese werden dann aus dem Scheduling herausgenommen, um falsche Berechnungen zu vermeiden. Wenn hingegen eine Konfigurationsänderung oder das Einspielen von Patches das System aus dem Gleichgewicht bringt, ermöglicht System-Rollback die Rückkehr zu einem früheren, nachweislich funktionierenden Systemzustand. Dank High-Availability-Szenarien und Load-Balancern, wird ein Service auch dann nicht beeinträchtigt, wenn verschiedene Komponenten ausfallen. Und mittels Virtualisierung kann nicht nur auf eine hohe Ressourcenauslastung, sondern durch ein entsprechendes Setup auch auf den Ausfall eines kompletten physischen Hosts effektiv reagiert werden.

Doch was hilft gegen fehlerhafte Software? Hier bleibt dem Administrator nur das regelmäßige Patchen – und das lässt sich ohne einen Neustart der Applikation oder einen Reboot nicht ohne Weiteres bewerkstelligen. Wie wir gleich sehen werden, können neue Technologien jedoch Abhilfe schaffen.

Mehr Sicherheit bei weniger Downtime – ein Paradoxon?

Ist es möglich, mehr Sicherheit zu gewährleisten, zugleich aber für weniger Downtime zu sorgen? Bevor wir dieses scheinbare Paradoxon auflösen, werfen wir einen Blick auf einen realen Anwendungsfall: den Linux-Kernel. Diesen zu patchen erfordert nicht nur den gegebenenfalls noch vertretbaren Neustart der darauf laufenden Applikationen, sondern den Neustart des gesamten Systems, sei es des physikalischen Hosts oder der Virtuellen Maschine. Vermeiden lassen sich Aktualisierungen des Kernels jedoch nicht. Allein im halben Jahr zwischen November 2015 und April 2016 wurden auf der Homepage der National Vulnerability Database (NVD) [1] insgesamt elf Sicherheitslücken im Linux-Kernel gemeldet, welche einen CVS-Score von 6 oder höher aufwiesen und deren Schweregrad damit als hoch eingestuft wurde [2].

Folgende Grafik (Stand: 2. Mai 2016) zeigt illustriert das Problem am Beispiel des Linux-Kernels von SUSE Linux Enterprise Server 12 SP1. Es gilt zu beachten, dass die gemeldeten Sicherheitslücken de facto in jedem Linux-Kernel vorhanden sind, egal ob dieser von SUSE, Red Hat, Ubuntu, Debian oder Gentoo kommt.

Bei Sicherheitslücken mit hohem Schweregrad schlagen Security-Teams üblicherweise Alarm und setzen alle Hebel in Gang, um für eine schnellstmögliche Beseitigung zu sorgen. Denn wenn es einem Angreifer gelingt, den Linux-Kernel zu kompromittieren, greifen lokale Sicherheitsmaßnahmen (z. B. SELinux, AppArmor und Firewalls) nur eingeschränkt oder überhaupt nicht mehr. Alle auf dem System laufenden Anwendungen sowie weitere Systeme im gleichen Netzwerk sind dann ebenfalls betroffen, soweit deren Informationen lokal vorhanden sind (zum Beispiel in einer Liste verfügbarer Systeme des Automounters in der Datei /etc/mount.map).

Sicherheitslücken werden nicht systematisch und gebündelt bekanntgemacht, sondern zumeist möglichst unmittelbar nach ihrer individuellen Entdeckung oder Behebung. Wer ein Höchstmaß an Sicherheit garantieren will, muss deshalb im Extremfall ständige Neustarts seines Systems vornehmen und hat mit wiederkehrenden Ausfallzeiten zu kämpfen. Wer andererseits auf die gewissenhafte Beseitigung von Sicherheitslücken verzichtet, setzt sein System und sein Unternehmen unkalkulierbaren Risiken aus, für die er im Zweifelsfall persönlich zur Rechenschaft gezogen werden kann. IT-Verantwortliche wünschen sich deshalb Mittel und Wege, den Linux-Kernel zu patchen, ohne ständig Applikationen stoppen und das System neu starten zu müssen.

Was ist Live Patch?

Bei Live Patch handelt es sich um eine Open Source-Technologie, die seit Version 4.0 ein Bestandteil des Linux-Kernels ist. Die Technologie erlaubt es, bestimmte Routinen und Funktionen des laufenden Linux-Kernels zur Laufzeit zu patchen – ohne das System anhalten oder sogar neustarten zu müssen. Live Patch basiert auf den beiden Vorgängerprojekten kGraft von SUSE und kpatch von Red Hat, die bereits seit 2014 existieren. Das Ziel von SUSE und Red Hat ist es, mit Live Patch eine einheitliche Open Source-Technologie zu etablieren und die Vorzüge von kGraft und kpatch zu vereinen. Zum aktuellen Stand fehlt Live Patch nur noch das Konsistenzmodell, das sicherstellt, dass ein Patch auch konsistent im System verankert werden kann. Dies wird von kGraft und kpatch unterschiedlich gehandhabt – und es wurde seitens der Entwickler noch nicht endgültig ausdiskutiert, wie Live Patch hier verfahren soll.

Wie das Patchen des Linux-Kernels mit Live Patch vonstatten geht, lässt sich schnell erläutern: Zuerst muss jede Linux-Kernel-Funktion mit einem 5-Byte-Header ausgestattet werden. Dies passiert während der Linux-Kernel kompiliert wird, also auf Distributorseite. Der 5-Byte-Header ist normalerweise leer, wird zur Laufzeit einfach übersprungen und hat somit keinen Einfluss auf die Performance. Wenn eine Linux-Kernel-Funktion aber wegen einer Sicherheitslücke gefixt werden muss, wird beim Einspielen der Live-Aktualisierung der Header der betroffenen Funktion geändert und eine überarbeitete Version der Funktion in den Speicher gelegt. Live Patch bedient sich des ftrace-Frameworks, um den Execution-Flow auf die neue, gefixte Funktion umzulenken ("call redirection"). Ein sehr vereinfachtes Beispiel eines Patchvorgangs sieht wie folgt aus:

Es sind natürlich unterschiedliche Szenarien vorstellbar, in denen das Patchen in dieser Form fehlschlagen muss oder in denen zumindest Inkonsistenzen entstehen:

Function-Inlining wird während des Kompilierens des Linux-Kernels angewendet, wenn der Compiler die Entscheidung trifft, eine Funktion aus Performancegründen in die aufrufende Funktion zu kopieren, anstatt einen Call zu nutzen. Auf diese Weise kann es passieren, dass eine fehlerhafte Funktion mehrfach im Linux-Kernel vorhanden ist. Beim Patchen muss deshalb auf DWARF-Informationen zurückgegriffen werden, um alle Kopien zu erwischen.

Statische Symbole im Linux-Kernel können ebenfalls Kopfzerbrechen verursachen, vor allem wenn diese nicht richtig exportiert und gleichzeitig von einer zu patchenden Funktion genutzt oder gesetzt werden. Glücklicherweise hält der Linux-Kernel eine Liste aller Symbole vor – sie kann genutzt werden, um beim Patchen auf dieses Problem zu reagieren.

Globale GCC-Compiler-Optimierungen wie "-O2", bescheren dem Linux-Kernel einen signifikanten Performance-Boost und aktivieren Optimierungsschalter wie etwa "-fipa-sra". Diese Option ist für den interprozeduralen, skalaren Austausch von Aggregaten und das Weglassen von nicht genutzten Funktionsparametern verantwortlich. Daraus ergeben sich drei Probleme. IPA-SRA erlaubt:

  1. Die Ersetzung des CALLs am Ende einer Funktion durch einen JMP, falls der CALL das letzte Statement der Funktion ist.
  2. Die Umwandlung von Parametern, deren Übergabe über eine Referenz erfolgt ist, in Werteparameter, falls der Wert sich nicht geändert hat.
  3. Die Existenz von Kernel-Funktionen in verschiedenen Varianten, einige davon mit weniger Parametern, wenn diese keinen Einfluss auf die Funktionsweise der Funktion haben.

Bei allen diesen Anwendungsfällen hilft die DWARF-Funktionalität des Linux-Kernels.

Das bereits angesprochene Konsistenzmodell ist die größte Hürde für Live Patch. Denn es kommt nur selten vor, dass lediglich eine einzige Funktion zu patchen ist. Üblicher ist es, dass eine Sicherheitslücke im Linux-Kernel mit einem ungünstigen Zusammenspiel mehrerer Linux-Kernel-Funktionen in Verbindung steht. Was nun, wenn die Anzahl der Funktionsparameter angepasst werden muss und dieser Schritt sich auf alle aufrufenden Funktionen auswirkt? Ähnlich problematisch sind jegliche Änderungen an Rückgabeparametern, auf die in allen weiteren Funktionen eingegangen werden muss. Im Falle von semantischen Änderungen an einer Funktion, sind also mit großer Sicherheit andere Linux-Kernel-Funktionen anzupassen.

Das Patchen mehrerer Funktionen erfordert ein passendes Konsistenzmodell. Hier weichen kGraft und kpatch voneinander ab. Während kGraft eine sogenannte "Lazy Migration" bevorzugt, die den Kernel nicht anhalten muss, um ihn zu patchen, wird bei kpatch auf "Activeness Safety" gesetzt, die den Kernel kurz anhält, um den Patchvorgang abzuschließen. Beide Ansätze haben ihre Vor- und Nachteile. Die Entwickler von Live Patch könnten entweder eines von ihnen übernehmen oder ein gänzlich neues Modell entwickeln.

Live Patch – eine lohnende Erweiterung für jedes Rechenzentrum?

Abschließend stellt sich die Frage, wie sinnvoll Live-Aktualisierungen des Linux-Kernels in der Praxis sein können. Dabei ist festzustellen: Nicht in jedem System stellen geplante Ausfallzeiten ein Problem dar. Einen geradezu exotischen Beleg für diese Feststellung liefern die Computersysteme des Hale-Teleskops der NASA auf Mount Palomar. Sie können jeden Tag problemlos gewartet werden – denn solange die Sonne am Himmel steht, kann das Teleskop ohnehin nichts sehen und ist daher außer Betrieb. Täglich besteht hier also ein mehrstündiges Wartungsfenster, in dem Patches eingespielt werden können.

Anders sieht es dort aus, wo Ausfallzeiten bares Geld kosten und wenig Raum für Wartungsfenster besteht. Systeme, die für Simulationen wochenlang ausgelastet sind, können nicht einfach angehalten und neu gestartet werden, ohne die Simulation abzubrechen. Das dringende Patchen von Landschaften, die aus hunderten oder tausenden von Virtuellen Maschinen bestehen, bedeutet hohe Kosten. Bei In-Memory-Anwendungen wie SAP HANA kann es gut und gerne 30 Minuten dauern, bis die Hardware die installierten 12-TB-Speicher initialisiert und überprüft hat. Nach dem Starten des Betriebssystems müssen dann bis zu 12 TB von der Festplatte in den Speicher geladen werden. Bei einer angenommenen Lesegeschwindigkeit von 500 MB/sec dauert das immerhin noch ca. sieben Stunden. Allein für das Einspielen von Kernel-Patches, ist eine solche Ausfallzeit schlicht nicht akzeptabel.

Wer in den Genuss von Live-Patching kommen will, findet in SUSEs kGraft und Red Hats kpatch bereits entsprechende Angebote. Ob und wann die beiden Distributoren Live Patch übernehmen, lässt sich nicht abschließend sagen.

DSU – Dynamische Software-Updates

Mitte des letzten Jahrhunderts, als Software noch ausschließlich interpretiert und auf Lochkarten gespeichert wurde, konnten Softwareupdates problemlos zur Laufzeit eingespielt werden. Die fehlerhafte Lochkarte wurde damals einfach durch eine verbesserte und farblich markierte Lochkarte im Stapel ersetzt. Da kompilierte Software um ein Vielfaches schneller ist als interpretierte Software, werden systemnahe Komponenten heutzutage nur in kompilierter Form bereitgestellt. Da das Kompilat im Speicher liegt und feste Strukturen aufweist, ist es hier nicht einfach, während der Laufzeit Updates einzuspielen. Erst Anfang der 1990er Jahre gab es mit dem PoDUS (Procedure-oriented Dynamic Updating System) von der Universität von Michigan, einen ersten akademischen Versuch in diese Richtung. Die neueste Technologie für Dynamische Software-Updates ist Live Patch im Linux-Kernel, das sich der distributorspezifischen Implementierungen von SUSE (kGraft) und Red Hat (kpatch) bedient.

Autor

Hannes Kühnemund

Im global aufgestellten SUSE Product Management trägt Hannes Kühnemund seit Februar 2015 die Verantwortung für diverse SLES-Komponenten wie YaST, zypper und snapper sowie die Produkte Live Patching und SLES for SAP Applications.
>> Weiterlesen
botMessage_toctoc_comments_9210