Stabile Kernel-Releases & Aktualisierung

Das stabile Release-Modell des Linux-Kernels wurde im Jahr 2005 eingeführt, als festgestellt wurde, dass das bestehende Kernel-Entwicklungsmodell (eine neue Version alle zwei bis drei Monate) den Anforderungen der meisten Benutzer nicht entsprach. Die Benutzer wollten, dass in diesen zwei bis drei Monaten Fehlerbehebungen vorgenommen werden, und Linux-Distributionen fanden es schwierig, die Kernel ohne Feedback der Kernel-Community auf dem neuesten Stand zu halten. Im Allgemeinen waren Versuche, einzelne Kernel sicher zu halten und mit den neuesten Bugfixes zu versehen, ein großer und verwirrender Aufwand für viele verschiedene Personen.

Stabile Kernel-Releases basieren direkt auf den Releases 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 des Kernel-Releases, an dessen Ende eine zusätzliche Nummer angehängt wird. Beispielsweise wird der 4.4-Kernel von Linus veröffentlicht, und die auf diesem Kernel basierenden stabilen Kernel-Releases werden dann mit 4.4.1, 4.4.2, 4.4.3 usw. nummeriert. Diese Sequenz wird normalerweise mit der Zahl 4.4.y abgekürzt, wenn auf einen stabilen Kernel-Release-Baum Bezug genommen wird. Jeder stabile Kernel-Release-Baum wird von einem einzelnen Kernel-Entwickler verwaltet, der für die Auswahl der benötigten Patches für das Release und die Verwaltung des Überprüfungs-/Release-Prozesses verantwortlich ist.

Stabile Kernel bleiben für die Dauer des aktuellen Entwicklungszyklus erhalten. Nachdem Linus einen neuen Kernel veröffentlicht hat, wird der vorherige stabile 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 Linux-Benutzer wollten, dass ein Kernel länger als nur ein paar Monate unterstützt wird. Als Reaktion darauf wurde die Long Term Supported (LTS)-Kernel-Version 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 einen Zeitraum von einem Jahr mindestens 2 Jahre.

Zum Zeitpunkt des Verfassens 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. Wöchentlich wird ein neuer Kernel 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 langfristig stabilen Kerneln, wer für sie verantwortlich ist und wie lange sie gewartet werden, finden Sie auf der Release-Seite von kernel.org .

Für LTS-Kernel-Releases werden durchschnittlich 6–8 Patches pro Tag akzeptiert, während die normalen stabilen Kernel-Releases 10–15 Patches pro Tag enthalten. Die Anzahl der Patches schwankt je nach Version, abhängig vom aktuellen Zeitpunkt der entsprechenden Entwicklungskernel-Version und anderen externen Variablen. Je älter ein LTS-Kernel ist, desto weniger Patches sind auf ihn anwendbar, da viele aktuelle Bugfixes für ältere Kernel nicht relevant sind. Je älter jedoch ein Kernel ist, desto schwieriger ist es aufgrund der Änderungen in der Codebasis, die zur Anwendung erforderlichen Änderungen zurückzuportieren. Auch wenn insgesamt weniger Patches angewendet werden, ist der Aufwand für die Wartung eines LTS-Kernels größer als für die Wartung des normalen stabilen Kernels.

Stabile Kernel-Patch-Regeln

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

  • Muss offensichtlich korrekt und getestet sein.
  • Darf nicht größer als 100 Zeilen sein.
  • Muss nur eine Sache reparieren.
  • Es muss ein Problem behoben werden, von dem berichtet wurde, dass es ein Problem darstellt.
  • Kann eine neue Geräte-ID oder Eigenart für Hardware sein, aber keine größeren neuen Funktionen hinzufügen.
  • Muss bereits mit dem Stammbaum von Linus Torvalds zusammengeführt sein.

Die letzte Regel „Muss bereits in den Baum von Linus Torvalds eingebunden sein“ verhindert, dass die Kernel-Community Fixes verliert. Die Community möchte niemals, dass ein Fix in eine stabile Kernel-Version einfließt, die noch nicht im Stammbaum von Linus Torvalds enthalten ist, sodass jeder, der ein Upgrade durchführt, nie einen Rückschritt sehen sollte. Dies verhindert viele Probleme, die bei anderen Projekten auftreten können, die einen Stable- und Entwicklungszweig unterhalten.

Kernel-Updates

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

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

Auf Linux-basierten Geräten mit großen Patch-Sets kann es aufgrund der großen Anzahl von Änderungen zwischen den einzelnen Releases (10-14.000 Änderungen pro Release) zu großen Problemen bei der Aktualisierung auf neuere Kernel kommen. Es ist besonders bekannt, dass SoC-Patchsets aufgrund ihrer Größe und der starken Modifikation des architekturspezifischen und manchmal Kernel-Kernel-Codes Probleme bei der Aktualisierung auf neuere Kernel haben. 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 Grundproblem, dass es schwierig ist, zum Zeitpunkt der Erstellung festzustellen, ob es sich bei einem Bugfix um einen Sicherheitsfix handelt oder nicht. Außerdem wird bei vielen Bugfixes erst nach einiger Zeit festgestellt, dass sie sicherheitsrelevant sind. Daher empfiehlt die Kernel-Community dringend, immer alle veröffentlichten Bugfixes zu übernehmen.

Wenn der Kernel-Community Sicherheitsprobleme gemeldet werden, werden diese so schnell wie möglich behoben und öffentlich im Entwicklungsbaum und in den stabilen Versionen veröffentlicht. Wie oben beschrieben werden die Änderungen fast nie als „Sicherheitsfix“ bezeichnet, sondern sehen eher 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 Problemmelder dies ankündigt.

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

Da Sicherheitslücken 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-Zweigen veröffentlicht.

Aufrechterhaltung eines sicheren Systems

Bei der Bereitstellung eines Geräts, das Linux verwendet, wird dringend empfohlen, alle LTS-Kernel-Updates vom Hersteller zu übernehmen und an die Benutzer weiterzugeben, nachdem ordnungsgemäße Tests ergeben 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 unmöglich, festzustellen, welche Patches „Sicherheitsprobleme“ beheben und welche nicht. Fast jede LTS-Version enthält mindestens einen bekannten und viele noch „unbekannte“ Sicherheitsupdates.
  • Wenn Tests ein Problem ergeben, wird die Kernel-Entwickler-Community schnell reagieren, um das Problem zu beheben.
  • Versuche, nur die von Ihnen ausgeführten Änderungen herauszufiltern, führen zu einem Kernelbaum, der nicht korrekt mit zukünftigen Upstream-Releases zusammengeführt werden kann.