In Brüssel feierte die Fosdem ihren 20sten Geburtstag. Wie immer stand die FLOSS-Community im Zentrum, und stellten Speaker zukunftsträchtige Projekte vor, etwa eBPF, eine neue In-Kernel-VM.
Eine Geschichtsstunde wollte der Kernellog-Autor Thorsten Leemhuis in seinem über 200-Slides-langen Eröffnungsvortrag nicht liefern. Vielmehr versuchte er, aus den historischen Ereignissen einige typische Entwicklungsmuster der Kernelentwicklung heraus zu meißeln. Da wäre zum Beispiel der Umgang mit großen Projekten. Gut 15 Jahre hat es gedauert, Linux in einen Echtzeit-Kernel zu verwandeln. Am Ende sei es Thomas Gleixner und seinen Mitstreitern jedoch in vielen kleinen Schritten und dank sehr viel Beharrlichkeit gelungen, die Idee von einem echtzeitfähigen Kernel umzusetzen. Noch in diesem Jahr wird das vorläufige Feature voraussichtlich offiziell freigeschaltet.
Kernel-Entwickler sind nicht selten Langstreckenläufer. Dank vieler kleiner Schritte bringen sie nicht nur Großprojekte erfolgreich ins Ziel. Sie programmieren auf diese inkrementelle Weise mitunter auch Features, die dann in der freien Wildbahn erstaunliche Karrieren hinlegen. Basierend auf Namespaces und Cgroups machte beispielsweise die Firma dotCloud Anfang der Zehnerjahre Furore und führte mit Docker eine Container-Technologie ein, die in heutigen Rechenzentren ihren Dienst tut, unter anderem als Engine in Kubernetes dient. Dockers Idee für die neuen Kernel-Features, aber auch die Umsetzung, hatte damals schlicht niemand auf dem Zettel. Die Docker-Entwickler bastelten aus der Kerneltechnologie einfach ein Open-Source-Produkt, das mit großem Erfolg eine Lücke füllte.
Mitten im Kernelspace
Auch ein anderes Projekt, den eBPF (extended Berkley Packet Filter), sollten Beobachter auf dem Schirm haben, empfahl Langzeit-Kernelbeobachter Leemhuis. Dabei handelt es sich um eine im Kernelspace angesiedelte Art von VM, die System-Events parst und es erlaubt, Code im Kernelspace auszuführen. Die Interaktionen mit dem Userspace laufen über so genannte 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 der Dtrace-Entwickler Brendan Gregg, dem sich dank eBPF die Option für ein Dtrace 2.0 öffnet. Kris Nova stellte in ihrem Clusterfuck-Talk auf der Fosdem wenig später Falco vor, eine Runtime-Security-Engine für Kubernetes. Die kann zur Laufzeit eines Clusters unter anderem ungewöhnliche und ungewollte Systemaufrufe blockieren. Dazu durchforstet die Software mit Hilfe von eBPF unter anderem die Syscalls, aber auch Container-Kontexte und die Meta- und Auditdaten von Kubernetes und untersucht diese auf bekannte Angriffsmuster hin. Das macht Falco zu einer Art “Wireshark für den Kernel”. Ergänzend brauchen Kubernetes-Admins dazu noch weitere Hilfsmittel, etwa OPA, den Open Policy Agent, dessen Kubernetes-Implementierung den Namen Gatekeeper trägt.
Container isolieren
Mit Containersicherheit setzte sich auch der Talk der IBM-Entwickler Mike Rapoport und James Bottomley auseinander. Sie suchen nach einem Weg, um Container sicher genug für den Einsatz ohne Extraschutz zu machen. Eines der zentralen Argumente gegen Container ist nämlich noch immer die fehlende Isolation im Speicher. Auch wenn die Angst oft übertrieben ist, packen Nutzer und Unternehmen die Container daher mit Vorliebe zusätzlich in VMs, um sie voneinander zu isolieren. Das zieht jedoch Overhead nach sich.
Bottomley und Rapoport suchen nun nach einer Möglichkeit, über den Linux-Kernel auch Adressräume im Speicher voneinander zu isolieren. In ihrem Talk zeigten sie die verschiedenen Ansätze, die möglich wären oder die sie bereits probiert haben, 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ärts kommen. Damit schließt sich dann auch der Kreis zum anfänglichen Vortrag: Ein paar Jahre werde es schon dauern, bis ihr Code einsatzbereit sei, schätzen die Entwickler. Aber das ist in der Kernelentwicklung ja keine Seltenheit und muss kein schlechtes Zeichen sein.
