Flexibler filtern
Neue Firewall-Technik für Linux bringt Elemente von Microkerneln
Der Linux-Kernel erhält eine weitere Firewall-Technik, bei der zur Laufzeit maßgeschneiderter Code den Netzwerkverkehr filtert. Zum sicheren und abgeschirmten Erzeugen dieses Codes hat Linux eine Infrastruktur bekommen, die den Kernel erheblich verändern könnte.
Der im August erwartete Linux-Kernel 4.18 bringt erste Teile des Bpfilter, einer neuen Paket-Filter-Technik für Firewalls. Admins brauchen sich allerdings nicht um ihr Iptables- oder Nftables-Know-how zu sorgen: Bpfilter soll lediglich den Unterbau ersetzen, den das altbekannte Iptables und sein designierter Nachfolger nutzen. Das soll sie deutlich schneller machen. Noch liegt dieses Ziel aber in weiter Ferne, denn bei 4.18 wurden nur Teile des Fundaments gelegt. Das hat dem eher monolithischen Linux-Kernel ganz nebenbei zu einer Infrastruktur verholfen, die prinzipiell eine Modularisierung in der Art von Microkerneln ermöglicht.
Genau passender Code
Der Clou von Bpfilter: Die Entscheidung über die Handhabung von Netzwerkpaketen erfolgt durch lokal erzeugten Programmcode, den der Kernel mit dem BPF ausführt. Dabei handelt es sich um eine prozessbasierte Virtual Machine, die allerdings simpler gestrickt ist als jene von .NET oder Java. Die VM ist ist auch als eBPF bekannt, da sie in den letzten Jahren aus dem Berkeley Packet Filter (BPF) hervorgegangen ist; mit ihm hat der aktuelle und bereits an vielen Stellen des Kernels genutzte BPF aber kaum noch etwas gemein.
Der BPF-Programmcode zum Filtern von Netzwerkpaketen mit dem Bpfilter wird für die jeweiligen Anforderungen maßgeschneidert. Das reduziert Verzweigungen im Code und verspricht, Overhead zu vermeiden. Damit der Prozessor den BPF-Code möglichst schnell ausführt, übersetzt der Kernel ihn auf gängigen Prozessor-Architekturen noch per Just-in-Time (JIT) in Maschinenbefehle. Darüber hinaus kann der Bpfilter den Netzwerkverkehr schon beim eXpress Data Path (XDP) abgreifen; der BPF-Code kann die Pakete dadurch schon kurz nach Empfang durch die Netzwerkhardware verarbeiten, bevor der mächtigere und daher trägere Netzwerkstack von Linux übernimmt.
Durch diese und andere Vorteile verspricht der neue Ansatz, effizienter zu arbeiten als die bislang von Iptables und Nftables genutzte Infrastruktur des Netfilter-Subsystems. Die ist zwar in C geschrieben, aber als universeller und flexibler Paket-Filter ausgelegt. Beim Abarbeiten des Regelsatzes muss der Code daher auch auf Eventualitäten gefasst sein, die lokal verwendete Regeln gar nicht nutzen. Das macht den Codepfad komplex, schließlich bietet der Netfilter immens viele Möglichkeiten, von denen Firewalls meist nur einen Bruchteil nutzen.
Userspace-Helferlein
Der Umstieg auf Bpfilter ist aber noch Zukunftsmusik, denn in 4.18 flossen lediglich Vorarbeiten ein. Sie schaffen eine Infrastruktur, mit der der Kernel den Filtercode lokal erzeugen soll. Das erfordert einen komplexen Übersetzungsvorgang, daher wollen die Entwickler die dazu nötigen Funktionen nicht im Code sehen, der mit Kernel-Rechten ausgeführt wird. Da es um eine sehr sicherheitskritische Kernel-Funktion geht, wollen sie die Aufgabe aber auch nicht an Werkzeuge delegieren, die unabhängig vom Kernel entwickelt werden und als normale Anwendungen laufen.
Die Programmierer haben daher für den Bpfilter einen Zwischenweg geschaffen: Erweiterung am User Mode Helper (UMH) und Module-Code, um den Kernel-Quellen beiliegende Userspace-Programme in Form von autark arbeitenden Kernel-Modulen mitliefern zu können. Beim Bpfilter soll dieses Modul ein Programm enthalten, das den Bpfilter-Code kompiliert und über Pipes mit dem Kernel interagiert. Das Programm läuft dabei unabhängig vom Userland der verwendeten Linux-Distribution, zugleich aber auch ohne Kernel-Privilegien – es kann daher abstürzen oder abgeschossen werden, ohne dass es den Kernel sonderlich juckt.
Mit diesem Fundament ist auch schon Rumpfcode für den Bpfilter in 4.18 eingeflossen, mit dem sich bereits ein Bpfilter.ko genanntes Kernel-Modul erzeugen lässt. Allerdings ist der bislang zu nichts nutze, denn die Entwickler haben die Schnittstellen und den rudimentären Code zurückgestellt, der BPF-Code zum Paketfiltern lokal erzeugt. Diese Funktionen soll bei einer der nächsten Kernel-Versionen folgen, sobald die grundlegende Infrastruktur die gröbsten Fehler abgeschüttelt hat. Bei Redaktionsschluss gab es noch einen größeres Problem: Bei aktivem Bpfilter lassen sich Kernel bislang nicht für andere Architekturen kompilieren („Cross Compile“); Torvalds hat bereits angedroht, den Bpfilter nochmal lahmzulegen, wenn die Entwickler das Problem nicht bis zur Fertigstellung von 4.18 am 6. oder 13. August beseitigen.
Performance-Gewinn
Nutzer sollen vom Bpfilter nicht viel mitbekommen, denn Letzterer soll sich über die Programmierschnittstellen ansprechen lassen, die klassische Filterwerkzeuge wie iptables oder das Nftables-Tool nft bereits jetzt zum Einrichten eines Netfilters nutzen. Frühen Messungen zufolge soll Bpfilter im Betrieb deutlich bessere Performance erzielen als Iptables und Nftables. Noch mehr Geschwindigkeit versprechen derzeit eher exotische Netzwerk-Chips, die einen BPF-Beschleuniger mitbringen, um BPF-Code direkt auszuführen. Solche Funktionen sind wichtig, damit Firewalls auch den Verkehr von 40G-Netzwerkkarten stemmen, schließlich rauschen dort in der Spitze rund 60 Millionen 64-Byte-Pakete pro Sekunde durch. Das überfordert den älteren Netfilter-Code bei Weitem.
Zukunftschancen
Es bleibt abzuwarten, ob das mit dem Bpfilter so klappt, wie die beteiligten Entwickler sich das denken; bis der neue Ansatz den alten vollständig ersetzen kann, müssen die Programmierer noch allerlei Funktionen implementieren, was einige Zeit dauern wird. Die Erfolgsaussichten des Bpfilter stehen aber ziemlich gut, denn er stammt von zwei langjährigen und angesehenen Netzwerk- und BPF-Entwicklern: Alexei Starovoitov und Daniel Borkmann. Sie hatten Unterstützung des langjährigen Kernel-Entwicklers David Miller, der den Netzwerk-Code von Linux betreut. Er witzelte bei der Annahme des Bpfilter-Fundaments für 4.18, dass der Wahnsinn jetzt beginnen könne („let the madness begin“). Greg Kroah-Hartman, einer der wichtigsten Linux-Entwickler, legte noch „Ja, das wird lustig“ nach („Yeah, this is going to be fun“).
Der Chef der Linux-News-Webseite LWN.net geht in einem Artikel zum Stand von Bpfilter bei 4.18 noch weiter: Er erwartet, der erweiterte User Mode Helper werde auch bei anderen Entwicklern auf Interesse stoßen, um Aufgaben auszulagern. Das ist wahrscheinlich, denn ähnlich wie bei Microkerneln kann das den Kernel entlasten, die Sicherheit verbessern und die Programmierung vereinfachen; ein zentraler Entwickler liebäugelt schon mit der Idee, Treiber für USB-Geräte mit Userspace-Modulen zu implementieren.
Der LWN.net-Autor führt zugleich aber an, man solle das Ganze bloß nicht Microkernel nennen, sonst würde es Leute womöglich aus der Fassung bringen. Damit spielt er auf eine 1992 in der Frühzeit von Linux geführte Debatte an, in der Minix-Erfinder Andrew S. Tanenbaum und Linux-Vater Linus Torvalds einige teilweise harsche Mails ausgetauscht haben. Auslöser war ein Statement von Tanenbaum, in dem er den monolithischen Linux-Kernel für obsolet erklärte, schließlich hätten Microkernel letztlich schon gewonnen. (thl@ct.de)