Betriebssysteme: Linux 4.18 bahnt den Weg für eine neue Firewall
Der Berkley Paket Filter (BPF) soll langfristig die veraltete Firewall Netfilter ersetzen, die inzwischen für die steigenden Übertragungsraten in Netzwerken zu langsam geworden ist. In Linux 4.18, dessen erste Testversion von Linux-Chef Linus Torvalds freigegeben wurde(öffnet im neuen Fenster) , ist dafür eine wesentliche Funktion eingebaut worden. Das eigentlich ausgereifte verteilte Dateisystem Lustre wurde kurzerhand aus dem Kernel entfernt, weil die Entwickler ihre Änderungen nicht in den offiziellen Kernel-Code einpflegen. Benutzer ohne Root-Rechte dürfen künftig sämtliche Dateisysteme über FUSE einbinden, was vor allem für Container wichtig ist. Und ein umstrittener Verschlüsselungsalgorithmus der NSA darf mit wesentlichen Dateisystemen genutzt werden.
Ganz lassen die Sicherheitslücken Spectre und Meltdown die Entwickler noch nicht los. Für die beiden Spectre-Versionen V1 und V2 gibt es jetzt auch Patches für 32-Bit-ARM-Prozessoren. Mit Speculative Store Bypass Disable (SSDB), das bereits in Linux 4.17 Einzug hielt, dort aber nur mit Intel-CPUs funktioniert, gibt es Gegenmaßnahmen gegen Spectre V4. Diese Lücke ermöglicht unter bestimmten Umständen das Auslesen eines Zeigers, auch wenn die Vorhersage durch die CPU noch nicht verifiziert wurde. In Linux 4.18 gibt es den Patch jetzt auch für AMD- und ARM64-Prozessoren. Diese Patches funktionieren jedoch nur mit aktualisierten Versionen der jeweiligen Firmware.
Wesentlicher Schritt für den Netfilter-Ersatz
Viel Arbeit haben die Linux-Hacker in die Erweiterung Bpfilter für den Berkley Packet Filter gesteckt. Wie ein Artikel bei LWM.net(öffnet im neuen Fenster) erläutert, steckt in der Entwicklung des Bpfilter-Mechanismus die Motivation, beispielsweise das Filtern von Netzwerkpaketen zu beschleunigen und langfristig das bislang verwendete Netfilter zu ersetzen, das inzwischen bei stetig steigend Übertragungsraten zu langsam geworden ist. Bpfilter hält Einzug in den aktuellen Kernel und schafft zunächst die Grundlage für ein beschleunigtes Filtersystem. Eine der Hürden, die überwunden werden mussten, war die Interaktion mit dem User-Space und die damit einhergehenden Sicherheitsbedenken, wenn mit einfachen Benutzerrechten erstellte Filterregeln im Kontext des Kernels laufen sollen. Denn der Plan, Bpfilter einfache Iptables-Regeln zu übergeben und in für den Just-In-Time-Compiler des BPF - den es mit Linux 4.18 auch für 32-Bit-x86-Systeme gibt - umzuwandeln, erfordert eben die Interaktion zwischen Benutzer und Kernel.
Dafür haben die Entwickler die sogenannten User-Mode-Blobs entworfen. Sie können einfach als Objekte erstellt werden und mit dem Modul Bpfilter.ko verlinkt werden. Damit kann der einen neuen Prozess und entsprechende Pipes erstellen, über die die Kommunikation mit dem Prozess stattfindet. Code, etwa ein Paketfilter, wird in das temporäre Dateisystem Tmpfs kopiert und dort auch ausgeführt.
Mehr als nur ein Paketfilter
Bpfilter steht noch am Anfang. Es gibt zwar bereits einen entsprechenden Paketfilter, der wurde in Linux 4.18 jedoch noch nicht umgesetzt, vor allem weil der Code der User-Mode-Blobs zunächst noch getestet werden muss. Langfristig dürfte aber genau diese Funktion weitreichender genutzt werden als nur in einem Paketfilter. Der Maintainer David Miller läutete den Patch mit den Worten(öffnet im neuen Fenster) ein: "Lasst den Wahnsinn beginnen."
Auch an anderer Stelle wurden Neuerungen am Berkley Paket Filter umgesetzt. Mit dem AF_XDP-Subsystem gelingt es künftig, BPF-Anwendungen im Benutzerkontext den Zero-Copy-Mechanismus im Netzwerk-Stack zu verwenden, der ebenfalls in Linux 4.18 hinzugekommen ist. Durch das einfache setzen eines Zeigers zum entsprechenden Code im Puffer wird so aufwendiges Kopieren umgangen. Eine weitere Neuerung bringt die Möglichkeit für BPF-Programme an einem Socket den Aufruf sendmsg() zu verwenden. Damit können die Programme beispielsweise IP-Adressen in ausgehenden Netzwerkpaketen umschreiben, wie es etwa beim Network Address Translation (NAT) verwendet wird.
Lustre ist raus, Namespace mit FUSE kommt rein
Das verteilte Dateisystem Lustre wurde aus dem Staging-Bereich des Linux-Kernels entfernt. Dort harrte es seit mehreren Jahren auf die offizielle Aufnahme in den Linux-Kernel. Da die Lustre-Entwickler aber das Dateisystem außerhalb des Kernels pflegen, und die Änderungen nicht in den nahezu verwaisten Kernel-Code integrierten, zogen sie den Groll des Kernel-Hackers Greg Kroah-Hartman(öffnet im neuen Fenster) auf sich. Zunächst mahnte er an, den Lustre-Code im Staging-Bereich auf einen aktuellen Stand zu bringen. Als das nicht geschah, warf er den Code kurzerhand aus Staging raus. Der Rückweg bleibt den Lustre-Entwicklern aber nicht verbaut. Sie könnten aktualisierten Code wieder einreichen, müssten ihn aber dann auch in den offiziellen Linux-Quellen weiter pflegen, schreibt Kroah-Hartman. Insgesamt haben die Kernel-Hacker die Aufräumarbeiten fortgesetzt, die mit dem Entfernen obsoleten Codes in Linux 4.17 begonnen hatte. Die Reduzierung sei nicht so drastisch wie in der letzten Kernel-Version aber dennoch bemerkbar, schreibt Torvalds.
FUSE darf jetzt in Namespaces automounten
Wichtig für Automount und Container ist die Möglichkeit, dass unprivilegierte Benutzer Dateisysteme einbinden können. Das geht jedoch nur mit einem gewissen Risiko einher, etwa wenn ein Dateisystem manipuliert wurde. Wird es dann mit Root-Rechten eingebunden, könnte es sich Zugriff auf weitere Kernel-Funktionen verschaffen. Aber auch einfach nur korrumpierte Dateisysteme könnten zu einem Systemabsturz führen. Deshalb sehen Entwickler wie Ted T'so das automatische Einbinden von Dateisystemen ohnehin äußerst kritisch. Die Verantwortung, stets ein sauberes Dateisystem zur Verfügung zu stellen, liege nicht bei den Dateisystem-Entwicklern, argumentiert er, es werde dort immer Fehler geben. Selbst die Verwendung von Prüfsummen und anderen Mechanismen könnten das nicht verhindern oder das Einbinden unnötig verlangsamen.
Die Entwickler um Eric Biederman wollen möglichst viele der Bedenken T'sos mit ihren jetzt eingereichten Patches ausräumen. Ab Linux 4.18 dürfen zumindest Benutzer, die Root-Rechte in ihrem Namensraum besitzen, Dateisysteme einbinden dürfen. Dabei werden auch die Geräteknotenpunkte (Device Nodes) im Namespace des Benutzers erstellt, sie bleiben dem Kernel weitgehend verborgen. Zudem dürfen nicht sämtliche Dateisysteme eingebunden werden, sondern nur solche, die explizit dafür freigeschaltet wurden. Zunächst ist nur das Fuse-Subsystem dafür vorgesehen. Diese Schnittstelle zwischen dem Mount-System des Kernels und dem Benutzer gibt es bereits lange. Sie kommt mit so ziemlich allen Dateisystemen zurecht, die auch der Linux-Kernel kennt, gilt als robust und hält auch nach dem neuen Verfahren korrumpierte Dateisysteme von Kernel fern. Aus Sicht von T'so stellt auch Fuse nach wie vor ein Sicherheitsrisiko dar. Biederman argumentiert hingegen, dass diese Lösung immer noch die sicherste sei, wenn weiterhin USB-Sticks oder Container im Userspace automatisch eingebunden werden sollen.
XFS setzt Modernisierungen um
Seit mehreren Kernel-Versionen wurde das Fundament des Dateisystems XFS überarbeitet, um die Grundlage für moderne Funktionen zu schaffen, die Btrfs oder ZFS längst mitbringen. Darauf aufbauend haben die XFS-Entwickler erste, für den Anwender sichtbare Neuerungen umgesetzt. Ab Linux 4.18 können XFS-Dateisysteme auch dann umbenannt werden, wenn sie im System eingebunden sind. Künftig kann XFS Daten und Swap-Dateien auch direkt per fallocate manipulieren. Zudem wurde die Prüfung von Metadaten verbessert. Damit im Zusammenhang stehen erste Arbeiten an der Reparaturfunktion, während das Dateisystem in Benutzung ist (Online). Außerdem wurde der Growfs-Code überarbeitet, mit dem sich die Größe des Dateisystems ändern lässt. Diese Arbeit soll den Weg für die Unterstützung von Subvolumes ebnen, die Btrfs und ZFS längst beherrschen. Bis beide Funktionen umgesetzt werden, werde es aber noch dauern, warnt Maintainer Derrick Wong(öffnet im neuen Fenster) .
Auch das Dateisystem Btrfs erhielt einige Verbesserungen, vor allem beim Kopieren von Dateien zwischen Volumes. Das soll nun deutlich schneller gehen, wenn es sich um große Verzeichnisse mit mehreren Millionen Einträgen handelt. Dafür werden künftig unnötige Zuweisungen verhindert und die Überprüfung bereits entfernter Inhalte wird verbessert. Ferner dürfen jetzt auch nicht privilegierte Benutzer Subvolumes auflisten, allerdings muss der Code auf seine Sicherheit untersucht werden. Das für Flashspeicher optimierte Dateisystem F2FS erhielt ebenfalls einige kleine Verbesserungen, darunter die Option fsync_mode=nobarrier , die die Zugriffe auf den Cache reduziert. Außerdem wurde Trim beziehungsweise Discard optimiert.
Kaum Änderungen bei Grafiktreibern, umstrittene NSA-Verschlüsselung
Bei den Grafiktreibern ist in Linux 4.18 vergleichsweise wenig hinzugekommen. Für die Grafikchips von Intel wurden Verbesserungen an HDCP (High-bandwidth Digital Content Protection) vorgenommen, dessen Unterstützung bereits in Linux 4.17 eingebaut wurde. Damit können verschlüsselte Blu-Rays, HD-DVDs oder TV-Signale auch über die in einigen Intel-CPUs verbauten Grafikeinheiten ausgegeben werden. Erste Arbeiten an der übernächsten Generation der Intel-Chips namens Icelake wurden ebenfalls eingepflegt. Ferner gibt es den neuen Treiber V3D DRM für den Videocore-V-Chip von Broadcom, der in den nächsten Versionen des Raspberry Pis verbaut werden soll. Der GV100-Chipsatz - alias Volta - von Nvidia, der in erster Linie auf einigen High-End-Quadro-Karten und dem Tesla V100 mit Fokus auf Machine Learning ausgeliefert wird, wird jetzt zumindest rudimentär vom freien Nouveau-Treiber unterstützt. Der Linux-Kernel kann automatisch die richtige Auflösung setzen, eine Hardware-Beschleunigung fehlt bislang jedoch, bis Nvidia die dazugehörige Firmware freigibt.
Für die nächste Generation der Grafikprozessoren von AMD, die unter dem Namen Vega 20 laufen, gibt es ebenfalls ersten Code. Auch für die Grafikeinheit Vega M, die auf der aktuellen Polaris-Generation basiert und in einigen Intel-CPUs integriert wird, gibt es erste Codeteile, die allerdings noch nicht alle Funktionen bereitstellen können. Weitere Arbeiten wurden an der Unterstützung von Leistungsprofilen und Verbesserungen an den Taktraten aktueller Grafikchips von AMD vorgenommen. Der in Linux 4.17 hinzugekommene AMDKFD-Treiber, mit dem auf die OpenCL- beziehungsweise ROCm-Fähigkeiten von AMDs Grafikkarten zugegriffen werden kann, lässt sich jetzt auch mit den aktuellen Vega-Karten nutzen. Der Linux-Kernel kann jetzt auch die Temperatur älterer Grafikeinheiten der Bristol-Ridge- und Stoney-Ridge-Reihe auslesen.
Verschlüsselungsalgorithmus von der NSA
Äußerst umstritten sind die Verschlüsselungsalgorithmen Speck und Simon vor allem deshalb, weil sie von der NSA entwickelt wurden und der US-Geheimdienst sich mit Details zu den Algorithmen zurückhält. Die NSA bewirbt Speck und Simon als effiziente Verschlüsselungsalternative, die vor allem für den Einsatz auf leistungsschwachen IoT-Geräten gedacht sind. Simon ist die Variante für den Einsatz auf Hardware-Chips, während Speck die Lösung von der Softwareseite her ist. Speck128 und Speck256 wurden bereits im Crypto-Stack in Linux 4.17 eingebaut. Jetzt hat Ted T'so die beiden Speck-Versionen für den Einsatz auf etlichen Dateisystemen freigegeben, etwa EXT4 und F2FS. Allerdings sollen die Verschlüsselungsalgorithmen lediglich auf den schwächsten Android-Smartphones zum Einsatz kommen, die keine andere Verschlüsselung unterstützen.
Dies und weitere Änderungen können in der Vorabversion Linux 4.18rc1 getestet werden, dessen Quellcode unter kernel.org(öffnet im neuen Fenster) erhältlich ist. Geht es nach der üblichen sechswöchigen Testphase, wird die finale Version von Linux 4.18 Ende Juli erscheinen.