Linux 5.18 kommt als "kleine Revolution"
Seite 2: Hardware-Angriffsschutz
Mit Kernel 5.13 verleibte sich Linux die aus Android stammende Control Flow Integrity (CFI) ein. Damit bietet Linux seither einen guten Software-Schutz gegen das Umlenken des Programmflusses bei indirekten Funktionsaufrufen durch das Manipulieren von Zeigerinhalten wie Rücksprungadressen. Das dahinterstehende Konzept ist reichlich komplex und rein software-basiert. Wie wir bereits zu 5.13 berichteten, wäre eine Unterstützung durch Hardware ideal. Durch den Verzicht auf eine spezielle Hardware ist der CFI-Patch jedoch auf jeder Plattform einsetzbar.
In puncto Hardware-Schutz greift Linux 5.18 das Indirect Branch Tracking (IBT) von Intel auf. Im Vergleich zu CFI ist IBT ein einfacherer, theoretisch auch schwächerer Ansatz. Allerdings ist diese Schutzlösung vollständig in Hardware gegossen. Damit ist es wesentlich performanter als CFI.
IBT führt neue CPU-Befehle endbr32 für 32-Bit und endbr64 für 64-Bit ein. Diese Befehle verhalten sich im Rechenwerk des Prozessors identisch zum noop. Sie führen also keinerlei Operation aus, außer Taktzyklen zu verbrauchen. Der Trick des Konzepts ist, dass der Prozessor bei jedem indirekten Funktionsaufruf erwartet, bei jedem Sprungziel auf genau ein endbr32 oder endbr64 zu treffen. Ist das nicht der Fall, löst das eine Exception aus und der vermutlich manipulierte Programmfluss kommt zum Erliegen.
Bugs mit falsch gesetztem Sprungziel tilgt dieser Mechanismus recht zuverlässig. So ist es statistisch doch eher unwahrscheinlich, dass bei einem falsch gesetztem Zeiger genau an dieser Stelle eine dieser CPU-Instruktionen steht. Ein Angreifer hingegen könnte das ganze Konzept dadurch zu Fall bringen, dass er seinem Sprungziel ein endbr32 beziehungsweise endbr64 voranstellt. Sind doch gerade bei bestimmten Overflow-Angriffen mit noop-Befehlen gepflasterte "Gleitwege" (noop-Sleds, Schlitten) doch ohnehin ein praktikables Mittel. Diese Schlitten mit den neuen Instruktionen anzureichern wäre sicherlich ein zumindest theoretisch gangbarer Weg.
IBT bietet damit weniger Schutz als das ausgefeilte CFI. Es ist aber durch den Hardware-Ansatz schneller und auch als zusätzliches Mittel einsetzbar. Bleibt aber grundsätzlich zunächst auf Intel-Prozessoren beschränkt.
Abstellgleis für ReiserFS
ReiserFS war das erste Journaling-Dateisystem für Linux. Hans Reiser und das Team seiner Firma Namesys hoben es Ende der 1990er aus der Taufe. 2001 floss es in Linux 2.4.1 ein und ist seither fester Bestandteil des Kernels. Bis 2006 war es zudem das Standarddateisystem von SuSE Linux.
Nach der Festnahme von Hans Reiser 2006 und den Mordermittlungen gegen ihn wurde es leiser um das Dateisystem. Nachdem er schließlich den Mord an seiner Frau 2008 nach einem mit der Staatsanwaltschaft geschlossenen Deal gestanden hatte, schwand die Anwenderbasis kontinuierlich. Die Firma Namesys wurde eingemottet. Schließlich hatte Edward Shishkin als ehemaliger Namesys-Mitarbeiter ReiserFS als Maintainer übernommen. Die Pflege des ReiserFS-Codes war damit gesichert, was aber den Anwenderschwund nicht aufhalten konnte.
Zusätzlich ist ReiserFS vom Jahr-2038-Problem betroffen. Im Januar 2038 werden die Zeitstempel im Dateisystem überlaufen und so auf den 1. Januar 1970 zurückspringen. Ein Patch ist bislang nicht in Sicht. Das Dateisystem wurde in Linux 5.18 nun als "deprecated" (veraltet) markiert. Es ist zudem vorgesehen, es 2025 aus dem Mainline-Kernel zu streichen.
Neuere Mainline-Kernel werden ReiserFS-Anwender dann nicht mehr nutzen können. Bei den Langzeit-Kerneln der LTS-Reihe sieht dies anders aus. So wird beispielsweise 5.15, welcher ReiserFS enthält, bis zum Ende seiner Laufzeit (aktuell 2028) das Dateisystem weiter enthalten. Auch LTS-Nachfolger bis 2025 werden ReiserFS enthalten, wenn auch mit dem "deprecated"-Marker. Schließlich ist spätestens bis Ende 2037 anzuraten, ReiserFS auf andere Dateisysteme zu migrieren.
Bei anderen Dateisystemen wie bestimmten Versionen von XFS und ext3 gibt es auch Jahr-2038-anfällige Varianten. Hierfür gibt es aber neuere Dateisystemversionen, die das Problem lösen, wenn auch die Dateisysteme migriert werden müssen. Bei ReiserFS ist es aktuell ungewiss, ob aktualisierte und 2038-taugliche Versionen erscheinen werden. Shishkin arbeitet zwar an ReierFS 5, konnte aber bislang keine bedeutenden Fortschritte erzielen. Es ist aktuell davon auszugehen, dass 2025 mit dem Wegfall von ReiserFS eine Ära leise zu Ende geht.
