Kdbus: Neue Interprozesskommunikation für den Linux-Kernel
Der D-Bus stellt Linux-Anwendungen eine Schnittstelle zur Kommunikation untereinander und mit Systemkomponenten zur Verfügung. Derzeit wird daran gearbeitet, den IPC-Mechanismus in den Linux-Kernel zu verlagern.
- Thorsten Leemhuis
Seit einigen Tagen stellt die Kernel-seitige D-Bus-Implementation Kdbus alle Funktionen zur Verfügung, die zum Betrieb des Gnome-Desktops nötig sind. Zudem kündigte Greg Kroah-Hartman an, sich wahrscheinlich schon in einigen Wochen um die Integration von Kdbus in den Linux-Kernel bemühen zu wollen.
Damit nähert sich der seit rund einem Jahr vorbereitete Mechanismus zur Interprozesskommunikation (IPC) langsam dem Punkt, an dem ihn experimentierfreudige Anwender ausprobieren können: Wenn alles so läuft, wie es sich die Kdbus-Entwickler vorstellen, könnte schon im Sommer ein Kernel verfügbar sein, der Anwendungen eine D-Bus-kompatible Schnittstelle zur Kommunikation untereinander und mit Linux-Systemkomponenten zur Verfügung stellt.
Einen allgemeinen Überblick zu Kdbus und dessen Entwicklungsstand hat Lennart Poettering kürzlich in einem Vortrag auf der linux.conf.au 2014 geliefert. Poettering erläutert darin, dass viele moderne Betriebssysteme außerhalb der Unix-Welt um einen zentralen High-Level-IPC-Mechanismus herum gebaut wurden; bei Unix und Linux habe es hingegen anfangs nur Low-Level-IPC-Techniken wie Pipes und Stream Sockets gegeben.
Diese Lücke habe bei modernen Linux-Distributionen der Userspace-Dienst D-Bus gestopft, ein leistungsfähiger IPC-Mechanismus mit zahlreichen Funktionen, die Gnome, KDE und viele andere Programme nutzen, um mit anderer Software zu kommunizieren oder Dienste erst bei Bedarf zu starten. Der Anwender merkt von all dem normalerweise nichts.
D-Bus-Design
D-Bus bewährt sich seit vielen Jahren, zeigt laut Poettering aber auch Schwächen – den ausgetauschten Nachrichten fehlen beispielsweise Zeitstempel, D-Bus ist erst spät im Boot-Prozess verfügbar und es gibt Mankos beim Zusammenspiel mit Sicherheitslösungen wie SELinux. D-Bus nutze zudem "barocken Code" und verwende übermäßig viel XML.
Das größte Problem indes: D-Bus eignet sich zwar gut zum Austausch von Kontrollnachrichten, um etwa dem Sound-Server zur Änderung der Wiedergabelautstärke aufzufordern, aber nicht zum Austausch großer Datenmengen. Mitschuld daran ist exzessives Kopieren von Daten, was sich bei einem Userspace-Dienst nicht ohne weiteres vermeiden lässt. Bei einer Call-Return-Message etwa, bei der der Sender das Ergebnis eines Methodenaufrufs beim Empfänger zurückgeliefert bekommt, gibt es laut Poettering zehn Kopier- und vier Validierungsprozesse mit ebenso vielen Context Switches.
Kdbus orientiert sich am D-Bus-Design, jedoch regelt hier Kernel-Code den Nachrichtenaustausch, was diese und andere Probleme von D-Bus vermeiden soll. So gibt es laut Poettering im schlimmsten Fall zwei Datenkopien, zwei Prüfungen und zwei Context Switches. Kdbus bietet zudem Zero-Copy, um das Kopieren ausgetauschter Daten ganz zu vermeiden, was sich laut Messungen der Entwickler aber erst bei Nachrichten ab 512 KByte Größe lohnt. Der Zero-Copy-Datenaustausch gelingt mit dem für Kdbus erfundenen Memfds, bei dem via Kdbus nur noch ein File Descriptor (FD) versendet wird, der auf einen Speicherbereich verweist. Siegel stellen sicher, das der sendende Prozess die Speicherbereiche nach dem Versenden nicht weiter verändert; das vermeidet Probleme, wie sie bei Shared Memory leicht auftreten.
Der Kernel-IPC-Mechanismus Kdbus (7 Bilder)
Auf die Frage eines Zuhörers, warum die Entwickler nicht einfach D-Bus optimiert hätten, statt die Funktion in den Kernel zu verlagern, erklärte Poettering: "Unser Weg zur Optimierung ist die Verlagerung in den Kernel", was ihm einige unterstützende Lacher einbrachte. Ferner betonte er, es würden keineswegs alle D-Bus-Funktionen in den Kernel gehievt, sondern nur bestimmte Teile; eine ganze Reihe von Funktionen würde im Userspace verbleiben.
API in Systemd
Einen Teil dieser Userspace-Funktionen wird Systemd stellen, dessen Entwicklerzweig bereits Kdbus-Unterstützung bietet. Dazu zählen Bibliotheken, über die Anwendungen Kdbus nutzen können. Zwar unterscheiden sich dessen Programmier-Schnittstellen von der D-Bus-API, aber D-Bus-Anwendungen können systemd-bus-proxyd nutzen, um den Nachrichtenaustausch von Kdbus erledigen zu lassen.
Der Vortrag geht noch auf weitere Details ein, durch die Kdbus ein besseres D-Bus sein soll; Bloomfilter etwa versprechen ein effizienteres Versenden von Broadcast-Nachrichten. Poettering nennt aber auch einen Bereich, in dem es noch viel zu tun gibt: Es fehle noch an Policy-Definitionen, die den Nachrichtenverkehr regeln, damit Angreifer über Kdbus keinen Schindluder treiben können.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Weitere Details liefern die Präsentationsfolien des Vortrags und dessen Video-Aufzeichnungen, die über die Webseite der Konferenz und YouTube abrufbar sind. Einen ähnlichen Vortrag will Poettering auf der FOSDEM halten, die Anfang Februar in Brüssel stattfindet,
In den Videos trägt der durch Pulseaudio und Systemd bekannte Entwickler ein T-Shirt mit der Aufschrift "Open Source Tea Party". Damit spielt er auf eine Aussage von Mark Shuttleworth in Richtung der Kritiker von Canonicals Display-Server Mir an, für die sich der Ubuntu-Sponsor später entschuldigte.
Kernel-Integration
Maßgeblich vorangetrieben wurde Kdbus und die zugehörige Infrastruktur von Greg Kroah-Hartman, Daniel Mack, Lennart Poettering und Kay Sievers. Kroah-Hartman hat kürzlich in einem Blog-Eintrag erläutert, wie sich Kdbus und der IPC-Mechanismus Binder aus dem Staging-Zweig des Linux-Kernels unterscheiden. Dabei erklärt er, Kdbus werde das in Android verwendete Binder möglicherweise gar nicht ersetzen können, weil die IPC-Mechanismen einen etwas anderen Ansatz hätten. Die Kurzerklärung: Binder sei an Prozessoren gebunden, D-Bus und somit auch Kdbus hingegen an den Speicher gebunden. In der längeren Erklärung nutzt er eine andere Analogie: Binder arbeitet eher wie ein Syscall, während D-Bus und Kdbus einem Protokoll zur Netzwerk-Kommunikation ähneln.
In eben diesem Blog-Posting erwähnt Kroah-Hartman auch, dass er sich bald um die Aufnahme von Kdbus in den Kernel bemühen will. Größe Diskussionen sind dabei nicht unwahrscheinlich, denn in den letzten Jahren wurden schon mehrere High-Level-IPC-Mechanismen zur Aufnahme in den Kernel eingereicht; alle blieben letztlich außen vor, weil sie die Qualitätsansprüche der Kernel-Entwickler nicht erfüllten (1, 2, 3, 4). Allerdings gehört Greg Kroah-Hartman zu den wichtigsten und erfahrensten Entwicklern des Linux-Kernels, daher stehen die Chancen recht gut, dass Kbus in nicht allzu ferner Zukunft in den Linux-Kernel einfließt.
Wenn es richtig schnell geht, könnte Kdbus schon Bestandteil von des Linux-Kernels 3.15 werden, der Ende Mai oder Anfang Juni erscheinen dürfte. In den Linux-Distributionen dürfte Kdbus D-Bus aber wohl erst ersetzen, wenn alles Nötige am Platz ist, damit Kdbus keine Sicherheitslücken aufreißt. (thl) (thl)
