Das Modell für stabile Releases des Linux-Kernels wurde 2005 eingeführt, als festgestellt wurde, dass das bestehende Modell für die Kernelentwicklung (ein neuer Release alle zwei bis drei Monate) nicht den Anforderungen der meisten Nutzer entsprach. Die Nutzer wollten in diesen zwei bis drei Monaten Fehlerkorrekturen und es war für Linux-Distributionen schwierig, die Kernel ohne Feedback von der Kernel-Community auf dem neuesten Stand zu halten. Im Allgemeinen war es ein großer und verwirrender Aufwand vieler verschiedener Personen, die einzelnen Kernel sicher zu halten und mit den neuesten Fehlerkorrekturen zu aktualisieren.
Stabile Kernel-Releases basieren direkt auf den Releases von Linus Torvalds und werden etwa alle zwei Wochen veröffentlicht, je nach verschiedenen externen Faktoren wie Jahreszeit, verfügbaren Patches und Arbeitslast der Maintainer. Die Nummerierung der stabilen Releases beginnt mit der Nummer der Kernel-Release und wird am Ende durch eine zusätzliche Zahl ergänzt. Beispielsweise wird der Kernel 4.4 von Linus veröffentlicht und die stabilen Kernel-Releases, die auf diesem Kernel basieren, werden dann mit 4.4.1, 4.4.2, 4.4.3 usw. nummeriert. Diese Sequenz wird in der Regel auf die Zahl 4.4.y verkürzt, wenn es sich um einen stabilen Kernel-Release-Tree handelt. Jeder stabile Kernel-Release-Tree wird von einem einzelnen Kernel-Entwickler verwaltet, der für die Auswahl der erforderlichen Patches für den Release und die Verwaltung des Überprüfungs-/Release-Prozesses verantwortlich ist.
Stabile Kernel werden während des gesamten aktuellen Entwicklungszyklus gepflegt. Nachdem Linus einen neuen Kernel veröffentlicht hat, wird der vorherige stabile Kernel-Release-Tree eingestellt und die Nutzer müssen auf den neueren veröffentlichten Kernel umsteigen.
Langfristig stabile Kernel
Nach einem Jahr mit diesem neuen Verfahren für stabile Releases wurde festgestellt, dass viele Linux-Nutzer einen Kernel länger als nur wenige Monate nutzen möchten. Als Reaktion darauf wurde der LTS-Kernel (Long Term Support) entwickelt. Der erste LTS-Kernel (2.6.16) wurde 2006 veröffentlicht. Seitdem wird einmal im Jahr ein neuer LTS-Kernel ausgewählt und von der Kernel-Community mindestens zwei Jahre lang gepflegt.
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. Wöchentlich wird ein neuer Kernel veröffentlicht. Aufgrund der Anforderungen einiger Nutzer und Distributionen werden einige ältere Kernel von Kernelentwicklern mit einem langsameren Release-Zyklus gepflegt. Informationen zu allen langfristig stabilen Kerneln, zu den zuständigen Personen und dazu, wie lange sie gepflegt werden, finden Sie auf der Seite kernel.org/releases.
Bei LTS-Kernel-Releases werden durchschnittlich 6 bis 8 Patches pro Tag akzeptiert, während die normalen stabilen Kernel-Releases 10 bis 15 Patches pro Tag enthalten. Die Anzahl der Patches schwankt je nach Release, je nachdem, wie weit der entsprechende Entwicklungskern fortgeschritten ist, und je nach anderen externen Variablen. Je älter ein LTS-Kernel ist, desto weniger Patches sind für ihn verfügbar, da viele aktuelle Fehlerkorrekturen für ältere Kernel nicht relevant sind. Je älter ein Kernel ist, desto schwieriger ist es jedoch, die erforderlichen Änderungen aufgrund der Änderungen an der Codebasis zu backporten. Auch wenn insgesamt weniger Patches angewendet werden, ist der Aufwand für die Pflege eines LTS-Kernels höher als für die Pflege des normalen stabilen Kernels.
Regeln für stabile Kernel-Patches
Die Regeln dafür, was einer stabilen Kernelversion hinzugefügt werden kann, sind seit ihrer Einführung nahezu unverändert geblieben. Sie werden unten zusammengefasst:
- Sie müssen offensichtlich korrekt und getestet sein.
- Darf nicht mehr als 100 Zeilen umfassen.
- Es muss nur eine Sache korrigiert werden.
- Es muss ein Problem behoben werden, das gemeldet wurde.
- Es kann sich um eine neue Geräte-ID oder um eine Eigenart der Hardware handeln, die aber keine wesentlichen neuen Funktionen hinzufügt.
- Muss bereits in den Linux-Entwicklungsbaum von Linus Torvalds eingegliedert sein.
Die letzte Regel, „Müssen bereits in den Linux-Tree von Linus Torvalds eingeflossen sein“, verhindert, dass die Kernel-Community Fehlerkorrekturen verliert. Die Community möchte nie, dass ein Fix in eine stabile Kernelversion aufgenommen wird, die nicht bereits im Tree von Linus Torvalds enthalten ist. So soll es bei Upgrades zu keinen Rückfällen kommen. Dadurch werden viele Probleme vermieden, die bei anderen Projekten auftreten können, die einen stabilen und einen Entwicklungszweig haben.
Kernel-Updates
Die Linux-Kernel-Community hat ihren Nutzern versprochen, dass durch ein Upgrade nie etwas kaputtgeht, das in einer früheren Version funktioniert hat. Dieses Versprechen gilt auch heute noch. Rückfälle treten zwar auf, aber diese Bugs haben die höchste Priorität und werden entweder schnell behoben oder die Änderung, die den Rückfall verursacht hat, wird schnell aus dem Linux-Kernel-Baum zurückgenommen.
Das gilt sowohl für die inkrementellen stabilen Kernel-Updates als auch für die größeren Hauptupdates, die alle drei Monate stattfinden. Die Kernel-Community kann diese Zusicherung jedoch nur für den Code geben, der in den Linux-Kernel-Baum eingegliedert wird. Code, der in den Kernel eines Geräts eingefügt wird und nicht in den kernel.org-Releases enthalten ist, ist unbekannt und Interaktionen damit können nicht geplant oder berücksichtigt werden.
Bei Geräten mit Linux-Betriebssystem und großen Patch-Sets können beim Upgrade auf neuere Kernel aufgrund der großen Anzahl von Änderungen zwischen den einzelnen Releases (10.000 bis 14.000 Änderungen pro Release) erhebliche Probleme auftreten. SoC-Patchsets sind aufgrund ihrer Größe und der umfangreichen Modifizierung des architekturspezifischen und manchmal auch des Kern-Kernel-Codes besonders anfällig für Probleme bei der Aktualisierung auf neuere Kernel. Daher beginnen die meisten SoC-Anbieter, die LTS-Releases für ihre Geräte zu standardisieren, damit diese Geräte Fehler- und Sicherheitsupdates direkt von der Linux-Kernel-Community erhalten können.
Sicherheit
Bei Kernel-Releases erklärt die Linux-Kernel-Community bestimmte Änderungen fast nie als Sicherheitsfehlerkorrekturen. Das liegt daran, dass es schwierig ist, bei der Erstellung zu bestimmen, ob es sich bei einer Fehlerkorrektur um eine Sicherheitskorrektur handelt oder nicht. Außerdem wird bei vielen Fehlerkorrekturen erst nach einiger Zeit festgestellt, dass sie sich auf die Sicherheit beziehen. Daher empfiehlt die Kernel-Community dringend, immer alle veröffentlichten Fehlerkorrekturen anzuwenden.
Wenn Sicherheitsprobleme der Kernel-Community gemeldet werden, werden sie so schnell wie möglich behoben und öffentlich in den Entwicklungsbaum und die stabilen Releases eingespeist. Wie oben beschrieben, werden die Änderungen fast nie als „Sicherheitsfix“ beschrieben, sondern sehen eher wie jeder andere Bugfix für den Kernel aus. So haben die betroffenen Parteien die Möglichkeit, ihre Systeme zu aktualisieren, bevor das Problem bekannt wird.
Weitere Informationen zum Melden von Sicherheitsfehlern an die Kernel-Community, damit sie so schnell wie möglich behoben werden, finden Sie unter Sicherheitsfehler im Linux-Kernel-Nutzer- und Administratorhandbuch auf www.kernel.org.
Da Sicherheitslücken vom Kernel-Team nicht öffentlich bekannt gegeben werden, werden CVE-Nummern für Linux-Kernel-bezogene Probleme in der Regel Wochen, Monate und manchmal Jahre nach der Zusammenführung des Fixes in die stabilen und Entwicklungszweige veröffentlicht.
Für ein sicheres System sorgen
Bei der Bereitstellung eines Geräts mit Linux empfehlen wir dringend, dass alle LTS-Kernel-Updates vom Hersteller übernommen und an die Nutzer gesendet werden, nachdem entsprechende Tests gezeigt haben, dass das Update funktioniert. Das bietet mehrere Vorteile:
- Die Releases wurden von den Kernel-Entwicklern als Ganzes und nicht in einzelnen Teilen geprüft.
- Es ist schwierig zu bestimmen, welche Patches „Sicherheitsprobleme“ beheben und welche nicht. Fast jeder LTS-Release enthält mindestens eine bekannte Sicherheitskorrektur und viele noch „unbekannte“.
- Wenn bei den Tests ein Problem festgestellt wird, reagiert die Kernel-Entwicklergemeinschaft schnell, um das Problem zu beheben.
- Wenn Sie versuchen, nur die von Ihnen ausgeführten Änderungen herauszufiltern, führt dies zu einem Kernel-Baum, der nicht korrekt mit zukünftigen Upstream-Releases zusammengeführt werden kann.