Seite 3: Erster Fixversuch und Rückbau

Inhaltsverzeichnis

Der exzessive Einsatz von set_fs() wurde jedoch trotz der offensichtlichen Sicherheitsprobleme nicht angefasst. Stattdessen wurde 2017 ein einfacher Patch von Thomas Garnier aufgenommen. Dieser Patch prüft bei jedem Systemcall, ob addr_limit mit dem originären Userspace-Segment übereinstimmt. Ist das nicht der Fall, löst der Patch eine Kernel Panic aus. Diese recht "brutale" Vorgehensweise ist umstritten, schottet den Kernel andererseits aber wirkungsvoll gegen Eindringlinge ab. Ein wesentlich weitreichenderer Aspekt bei diesem Patch ist der Performance-Impact. Diese Prüfung bei jedem Systemcall auszuführen, verbrennt ungemein CPU-Zeit – in den meisten Fällen für nichts.

Zumindest brachte besagter Patch wieder Leben in die Diskussion. Schließlich nahm sich Entwickler Christoph Hellwig des Themas an: Selbst im relativ neuen Code von BPF (Berkeley Packet Filter) hatte sich die unsichere set_fs()-Praxis durchgesetzt. Um dem entgegen zu wirken, führte Hellwig mit einem Patch einen neuen sockptr_t ein, der angibt, ob er Zeiger im Kernel- oder Userspace nutzt. Auf der Basis dieses Merkmals kann der Kernel Helper-Funktionen zum Einsatz bringen, die das Kopieren von Daten zwischen Kernel- und Userspace übernehmen oder eben doch set_fs() – aber in kontrollierter Form – zum Einsatz bringen

Damit konnten die set_fs()-Aufrufe zunächst aus BPF (Berkeley Packet Filter)-Programmen entfernt werden, in denen sie den Auslöser für Hellwigs Bemühungen darstellten. Anschließend standen die Helper-Funktionen dann Pate, um die set_fs()-Nutzung auch in anderen Teilen des Systems zu reduzieren.

Wegfall ohne größere Probleme

Auf bestehende Anwendungsfälle sollte der Umstieg auf die Helper-Funktionen keine (negativen) Auswirkungen haben. Lediglich die Implementierung von splice() kann Probleme bereiten: Ist die Datenquelle ein Gerät, das splice_read() nicht unterstützt, funktioniert splice() nicht mehr wie gewohnt. Allerdings scheinen alle betroffenen Kernel-Maintainer bereits Lösungen in der Schublade zu haben, um splice_read() "nachzurüsten".

Der Wegfall von set_fs() sollte daher nach aktuellem Stand keine weitreichenden Inkompatiblitäten erzeugen. Lediglich Hersteller von Treibern, die nicht im Kernel-Tree enthalten sind, sollten ihren Code durchkämmen und sich für ein Leben ohne set_fs() rüsten.

Aktueller Stand

Bereits hinter den Kulissen Linux 5.9 war einiges für den Wechsel vorbereitet worden. Linus Torvalds führt die Bereinigung in x86, PowerPC, S390 und RISC-V als "abgeschlossen" an. Andere Architekturen wie beispielsweise Motorola 68k, MIPS, ARM und Sparc setzen den set_fs()-Mechanismus noch ein. Torvalds spricht in der Ankündigung zu Linux 5.10-rc1 von einem getanen Anfang und hofft, dass die anderen Architekturen ebenfalls von dem "historischen Modell" Abschied nehmen können und werden – auch wenn dies noch einige Zeit in Anspruch nehmen dürfte.

(ovw)