Stabile Kernel-Veröffentlichungen und -Updates

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Das stabile Versionsmodell des Linux-Kernels wurde 2005 eingeführt, als festgestellt wurde, dass das bestehende Kernel-Entwicklungsmodell (eine neue Version alle 2-3 Monate) die Anforderungen der meisten Benutzer nicht erfüllte. Die Benutzer wollten, dass in diesen 2-3 Monaten Bugfixes vorgenommen wurden, und Linux-Distributionen fanden es schwierig, die Kernel ohne Feedback von der Kernel-Community auf dem neuesten Stand zu halten. Im Allgemeinen waren Versuche, einzelne Kernel sicher zu halten und mit den neuesten Bugfixes aufzubewahren, ein großer und verwirrender Aufwand von vielen verschiedenen Personen.

Stabile Kernel-Veröffentlichungen basieren direkt auf den Veröffentlichungen von Linus Torvalds und werden etwa jede Woche veröffentlicht, abhängig von verschiedenen externen Faktoren (Jahreszeit, verfügbare Patches, Arbeitsbelastung des Betreuers usw.). Die Nummerierung der Stable-Releases beginnt mit der Nummer der Kernel-Release, an deren Ende eine zusätzliche Nummer angehängt wird. Beispielsweise wird der 4.4-Kernel von Linus veröffentlicht, und dann werden die stabilen Kernel-Versionen, die auf diesem Kernel basieren, mit 4.4.1, 4.4.2, 4.4.3 usw. nummeriert. Diese Sequenz wird normalerweise mit der Nummer 4.4.y abgekürzt, wenn auf einen stabilen Kernel-Release-Baum verwiesen wird. Jeder Stable-Kernel-Release-Tree wird von einem einzelnen Kernel-Entwickler gepflegt, der für die Auswahl der benötigten Patches für das Release und die Verwaltung des Review-/Release-Prozesses verantwortlich ist.

Stabile Kernel werden für die Dauer des aktuellen Entwicklungszyklus beibehalten. Nachdem Linus einen neuen Kernel veröffentlicht hat, wird der vorherige Stable-Kernel-Release-Baum gestoppt und Benutzer müssen zum neueren veröffentlichten Kernel wechseln.

Langzeitstabile Kernel

Nach einem Jahr dieses neuen stabilen Veröffentlichungsprozesses wurde festgestellt, dass viele verschiedene Benutzer von Linux wollten, dass ein Kernel länger als nur ein paar Monate unterstützt wird. Als Reaktion darauf wurde die Kernel-Version Long Term Supported (LTS) erstellt, wobei der erste LTS-Kernel (2.6.16) im Jahr 2006 veröffentlicht wurde. Seitdem wird einmal im Jahr ein neuer LTS-Kernel ausgewählt und die Kernel-Community pflegt diesen Kernel für a mindestens 2 Jahre.

Zum Zeitpunkt der Erstellung dieses Artikels sind die LTS-Kernel die Versionen 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y und 5.10.y. Ein neuer Kernel wird wöchentlich veröffentlicht. Aufgrund der Bedürfnisse einiger Benutzer und Distributionen werden einige zusätzliche ältere Kernel von Kernel-Entwicklern in einem langsameren Veröffentlichungszyklus gepflegt. Informationen zu allen langzeitstabilen Kerneln, wer für sie verantwortlich ist und wie lange sie gewartet werden, finden Sie auf der Releases-Seite von kernel.org .

LTS-Kernel-Veröffentlichungen nehmen durchschnittlich 6-8 Patches pro Tag an, während die normalen stabilen Kernel-Veröffentlichungen 10-15 Patches pro Tag enthalten. Die Anzahl der Patches schwankt je nach Version aufgrund der aktuellen Zeit der entsprechenden Entwicklungskernel-Version und anderer externer Variablen. Je älter ein LTS-Kernel ist, desto weniger Patches sind darauf anwendbar, da viele aktuelle Bugfixes für ältere Kernel nicht relevant sind. Je älter ein Kernel ist, desto schwieriger ist es jedoch, die Änderungen, die angewendet werden müssen, aufgrund der Änderungen in der Codebasis zurückzuportieren. Während also möglicherweise eine geringere Anzahl von Patches angewendet wird, ist der Aufwand für die Wartung eines LTS-Kernels größer als für die Wartung des normalen Stable-Kernels.

Stabile Kernel-Patch-Regeln

Die Regeln für das, was zu einer stabilen Kernel-Version hinzugefügt werden kann, sind seit ihrer Einführung nahezu identisch geblieben und werden im Folgenden zusammengefasst:

  • Muss offensichtlich korrekt und getestet sein.
  • Darf nicht größer als 100 Zeilen sein.
  • Muss nur eine Sache beheben.
  • Muss etwas beheben, das als Problem gemeldet wurde.
  • Kann eine neue Geräte-ID oder Eigenart für Hardware sein, fügt aber keine größeren neuen Funktionen hinzu.
  • Muss bereits in den Stammbaum von Linus Torvalds eingefügt werden.

Die letzte Regel „Muss bereits in den Baum von Linus Torvalds gemergt werden“ verhindert, dass die Kernel-Community Fixes verliert. Die Community möchte niemals, dass ein Fix in eine stabile Kernel-Version einfließt, die sich nicht bereits im Baum von Linus Torvalds befindet, sodass jeder, der aktualisiert, niemals eine Regression sehen sollte. Dies verhindert viele Probleme, die andere Projekte haben können, die einen stabilen und einen Entwicklungszweig unterhalten.

Kernel-Updates

Die Linux-Kernel-Community hat ihrer Benutzerbasis versprochen, dass kein Upgrade jemals etwas beschädigen wird, das derzeit in einer früheren Version funktioniert. Dieses Versprechen gilt noch heute. Regressionen passieren, aber das sind die Fehler mit der höchsten Priorität und werden entweder schnell behoben oder die Änderung, die die Regression verursacht hat, wird schnell aus dem Linux-Kernelbaum zurückgesetzt.

Dieses Versprechen gilt sowohl für die inkrementellen Stable-Kernel-Updates als auch für die größeren Major-Updates, die alle drei Monate stattfinden. Allerdings kann die Kernel-Community dieses Versprechen nur für den Code geben, der in den Linux-Kernelbaum eingebunden wird. Jeglicher Code, der in den Kernel eines Geräts eingebunden wird, der nicht in den Kernel.org- Versionen enthalten ist, ist unbekannt, und Interaktionen damit können niemals geplant oder auch nur in Betracht gezogen werden.

Auf Linux basierende Geräte mit großen Patch-Sets können aufgrund der großen Anzahl von Änderungen zwischen den einzelnen Releases (10-14.000 Änderungen pro Release) große Probleme beim Update auf neuere Kernel haben. Es ist besonders bekannt, dass SoC-Patchsets Probleme mit der Aktualisierung auf neuere Kernel haben, da sie sehr groß sind und den architekturspezifischen und manchmal den Kernel-Code stark modifizieren. Infolgedessen beginnen die meisten SoC-Anbieter damit, die Verwendung der LTS-Versionen für ihre Geräte zu standardisieren, sodass diese Geräte Fehler- und Sicherheitsupdates direkt von der Linux-Kernel-Community erhalten können.

Sicherheit

Bei Kernel-Releases deklariert die Linux-Kernel-Community bestimmte Änderungen fast nie als Sicherheitsfixes . Dies liegt an dem grundlegenden Problem, dass es schwierig ist festzustellen, ob ein Bugfix zum Zeitpunkt der Erstellung ein Sicherheitsfix ist oder nicht. Außerdem werden viele Bugfixes erst nach längerer Zeit als sicherheitsrelevant eingestuft, daher empfiehlt die Kernel-Community dringend, immer alle veröffentlichten Bugfixes zu übernehmen.

Wenn der Kernel-Community Sicherheitsprobleme gemeldet werden, werden sie so schnell wie möglich behoben und öffentlich an den Entwicklungsbaum und die stabilen Versionen weitergegeben. Wie oben beschrieben, werden die Änderungen fast nie als "Sicherheitsfix" bezeichnet, sondern sehen aus wie jeder andere Bugfix für den Kernel. Dies geschieht, um betroffenen Parteien die Möglichkeit zu geben, ihre Systeme zu aktualisieren, bevor der Melder des Problems es ankündigt.

Einzelheiten zum Melden von Sicherheitsfehlern an die Kernel-Community, damit diese so schnell wie möglich gelöst und behoben werden, finden Sie unter Sicherheitsfehler im Handbuch für Benutzer und Administratoren des Linux-Kernels unter www.kernel.org .

Da Sicherheitsfehler vom Kernel-Team nicht öffentlich bekannt gegeben werden, werden CVE-Nummern für Probleme im Zusammenhang mit dem Linux-Kernel normalerweise Wochen, Monate und manchmal Jahre nach der Zusammenführung des Fixes in den Stable- und Development-Zweig veröffentlicht.

Aufrechterhaltung eines sicheren Systems

Bei der Bereitstellung eines Geräts, das Linux verwendet, wird dringend empfohlen, dass alle LTS-Kernel-Updates vom Hersteller übernommen und an die Benutzer verteilt werden, nachdem ordnungsgemäße Tests gezeigt haben, dass das Update gut funktioniert. Dies hat mehrere Vorteile:

  • Releases wurden von den Kernel-Entwicklern als Ganzes überprüft, nicht in einzelnen Teilen.
  • Es ist schwierig, wenn nicht sogar unmöglich, festzustellen, welche Patches „Sicherheitsprobleme“ beheben und welche nicht. Fast jede LTS-Version enthält mindestens einen bekannten Sicherheitsfix und viele noch „unbekannte“.
  • Wenn das Testen ein Problem zeigt, wird die Kernel-Entwickler-Community schnell reagieren, um das Problem zu lösen.
  • Versuche, nur die von Ihnen ausgeführten Änderungen herauszufiltern, führen zu einem Kernel-Baum, der mit zukünftigen Upstream-Versionen nicht korrekt zusammengeführt werden kann.