Fosdem: Linux ist Entwicklung auf der Langstrecke
Den 20. Geburtstag ihrer Fosdem-Konferenz in Brüssel nutzen die Organisatoren für einen eigenen History-Track. Darin wird aber nicht nur zurückgeblickt, sondern auch vorausgeschaut. So hat auch der Kernel-Log-Autor Thorsten Leemhuis in seinem langen Eröffnungsvortrag der Fosdem(öffnet im neuen Fenster) keine schnöde Geschichtsstunde gehalten. Vielmehr arbeitete er aus den historischen Ereignissen einige typische Entwicklungsmuster der Kernel-Entwicklung heraus.
Da wäre zum Beispiel der Umgang mit großen Projekten und Problemen. So hat es etwa gut 15 Jahre gedauert, Linux in einen Echtzeit-Kernel zu verwandeln. Am Ende sei es dem Verantwortlichen Thomas Gleixner und seinen Mitstreitern jedoch in vielen kleinen Schritten und dank sehr viel Beharrlichkeit gelungen, die Idee von einem echtzeitfähigen Kernel umzusetzen, sagte Leemhuis. Noch in diesem Jahr wird die Funktion voraussichtlich offiziell im Hauptzweig des Linux-Kernels freigeschaltet.
In vielen kleinen Schritten weite Strecken zurücklegen
Aber nicht nur dieses Beispiel zeigt, dass sich Kernel-Entwickler nicht selten an der Langstrecke versuchen. Dank vieler kleiner Schritte bringen sie nicht nur Großprojekte erfolgreich ans Ziel. Sie programmieren auf diese inkrementelle Weise mitunter auch Funktionen, die sich dann später erstaunlich entwickeln.
Basierend auf den bereits im Kernel existierenden Namespaces und Cgroups sorgte beispielsweise die Firma Dotcloud für Furore und führte mit Docker eine Containertechnologie ein, die in heutigen Rechenzentren eingesetzt wird und unter anderem als Engine in Kubernetes dient. Dockers Idee für die Nutzung der Kernel-Funktionen, aber vor allem auch deren Umsetzung waren damals quasi Alleinstellungsmerkmale. Die Docker-Entwickler bastelten aus der Kernel-Technologie in wenigen Jahren ein Open-Source-Produkt, das mit großem Erfolg eine Lücke füllte.
Langer Umbau mitten im Kernel-Space
Auch ein anderes Projekt, den eBPF (extended Berkley Packet Filter), sollten Interessierte genau verfolgen, empfiehlt Langzeit-Kernel-Beobachter Leemhuis. Dabei handelt es sich um eine im Kernel-Space angesiedelte spezielle Art von Virtual Machine (VM), die System-Events verarbeitet und es ermöglicht, Code im Kernel-Space auszuführen. Die Interaktionen mit dem Userspace laufen über sogenannte Maps (Key-Value-Stores), die Programme dürfen nicht Turing-komplett sein und der Userspace darf nur lesend auf die von der eBPF generierten Werte zugreifen.
Tatsächlich gibt es bereits erste Nutzer dieser neuen Technologie, wie etwa den Dtrace-Entwickler Brendan Gregg, dem sich dank eBPF die Option für ein Dtrace 2.0 eröffnet . Das ursprünglich vom Computer- und Softwarehersteller Sun Microsystems erstellte Analysewerkzeug Dtrace stand jahrelang wegen Lizenzproblemen nicht ohne weiteres für Linux bereit. Die fortdauernden Arbeiten von Gregg und der Kernel-Community, um BPF systematisch zu erweitern, schufen letztlich aber einen Ersatz für Dtrace.
Zusätzlich stellte die Entwicklerin Kris Nova in ihrem Clusterfuck-Vortrag auf der Fosdem(öffnet im neuen Fenster) wenig später das Projekt Falco vor, eine Runtime Security Engine für Kubernetes. Diese kann zur Laufzeit eines Clusters unter anderem ungewöhnliche und ungewollte Systemaufrufe blockieren.
Dazu durchsucht die Software mit Hilfe von eBPF unter anderem die Systemaufrufe, überprüft aber auch Container-Kontexte sowie die Meta- und Audit-Daten von Kubernetes und untersucht diese auf bekannte Angriffsmuster hin. Das macht Falco zu einer Art "Wireshark für den Kernel" . Möglich machen das erst die jahrelange Arbeit an Containertechnik und eBPF.
Container besser isolieren
Mit Containersicherheit setzten sich die Entwickler Mike Rapoport und James Bottomley auseinander(öffnet im neuen Fenster) . Sie suchen nach einem Weg, Container ohne zusätzliche Werkzeuge sicher genug für den Einsatz zu machen. Eines der zentralen Argumente gegen Container ist laut dem Vortrag nämlich noch immer die fehlende Isolation im Speicher. Auch wenn die Angst oft übertrieben scheint, stecken Nutzer und Unternehmen die Container daher mit Vorliebe zusätzlich in VMs, um sie voneinander zu isolieren. Dafür gibt es inzwischen eine Vielzahl unterschiedlicher Projekte, das zieht jedoch einen Overhead nach sich.
Bottomley und Rapoport suchen nun nach einer Möglichkeit, über den Linux-Kernel auch Adressräume im Speicher direkt voneinander zu isolieren. In ihrem Talk zeigten sie die verschiedenen Ansätze – mögliche und bereits ausprobierte -, um gleich auch die Probleme aufzulisten, die sich aus den jeweiligen Ansätzen ergeben.
Es scheint ein mühsamer Weg zu sein, den die Forscher da vor sich haben und auf dem sie wohl wieder mal nur in kleinen Schritten vorwärtskommen können. Ein paar Jahre werde es schon dauern, bis ihr Code einsatzbereit sei, schätzen die Entwickler. Aber das ist in der Kernel-Entwicklung ja keine Seltenheit und muss kein schlechtes Zeichen sein.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.