Aus Linux-Magazin 07/2015

Linux 4.1: Kein Kdbus, aber verschlüsseltes Ext 4 und Trace-FS

© yuanyuan xie, 123RF

Im nächsten Linux-Kernel kann sich das Dateisystem Ext 4 selbst verschlüsseln. Die Interprozess-Kommunikation Kdbus wurde zwar hitzig diskutiert, hat es aber nicht in den Kernel 4.1 geschafft.

An Kdbus, einer Dbus-basierten Interprozess-Kommunikation für den Kernel, arbeiten die Entwickler um Systemd-Erfinder Lennart Poettering und Kernelentwickler Greg Kroah-Hartman seit über einem Jahr. Bereits im Oktober 2014 schlug Kroah-Hartman vor, den Code in den Kernel aufzunehmen, Mitte April 2015 gab es jetzt einen offiziellen Pull-Request [1]. Der sorgte auf der Kernel-Mailingliste für kontroversen Gesprächsstoff.

Als Daemon komme Dbus in seiner aktuellen Umsetzung nicht mit großen Datenmengen klar, wie sie Polkit oder Pulseaudio benötigen, erklärte Kroah-Hartman seinen Pull-Request. Es sei zu langsam, weshalb man den Weg über Unix Domain Sockets (ODS) gehen müsse, was aber den Code dupliziere. Kdbus könne Systemaufrufe wesentlich schneller abwickeln. Würden die Nachrichten zudem Metadaten enthalten, könne dies das Debuggen und Filtern vereinfachen. Nicht zuletzt lasse sich Dbus nur unzureichend in das Sicherheitsframework SE Linux integrieren und sei zudem äußerst fehleranfällig.

Antrag abgelehnt!

Doch vor allem Sicherheitsbedenken verhinderten offenbar, dass Linus Torvalds den Kdbus-Code auf Anhieb in den Kernel 4.1 aufnahm. Er kritisierte, dass die Prozessdaten auch Metadaten übertragen und so zu viel über das System verraten – etwa mit welchen Berechtigungen es ein Gerät anspricht. In der jetzigen Umsetzung würden sich die Metadaten laut Torvalds zu einfach protokollieren lassen: “Seht ihr wirklich nicht die Implikationen für die Privatsphäre? Es verwandelt Privatsphäre-Verletzungen von einer ,Da müsst Ihr dran arbeiten’- in eine ,Das passiert häufig aus Versehen’-Geschichte.” Kroah-Hartman setzte dagegen, dass die von Torvalds kritisierten Berechtigungen und Zeitstempel benötigt würden, um zum Beispiel Geräte besser einzubinden.

Problemfall Dbus?

Andere Kritiker zielten direkt auf Dbus. Wenn es so anfällig sei, warum wolle man es dann in den Kernel holen? Sie plädierten für ein anderes IPC-System im Kernel, mit mehr Fähigkeiten als Dbus, das vielmehr dessen Schwächen behebe, also eine “kleine, generische Multicast-IPC-Methode, die netzwerkübergreifend funktioniert” [2].

Auch hier hielt Kroah-Hartman dagegen. Bislang habe sich schlicht niemand gefunden, der eine “Allzweck-IPC” entwickelt habe. Das bedeute für ihn, dass es schlicht nicht möglich sei oder niemand sie wirklich wolle. Dem Kdbus-Mann sprang überraschend Dbus-Entwickler Havoc Pennington zur Seite. Er gab zu, dass Dbus nicht perfekt sei, erklärte aber auch, warum die Vorteile die Nachteile klar überwiegen würden.

Greg Kroah-Hartman will Kdbus im Kernel sehen.

Greg Kroah-Hartman will Kdbus im Kernel sehen.

Nach diesem ersten Schlagabtausch scheint die Diskussion noch nicht am Ende zu sein. Vermutlich passen die Kdbus-Entwickler nun ihren Code an und starten im Merge-Fenster für Linux 4.2 einen erneuten Pull-Request.

Ext 4 verschlüsselt, Btr-FS beschleunigt

Weniger Wirbel erzeugten die anderen Neuerungen für Linux 4.1, das vermutlich Anfang Juni erscheint. Weil Google es für sein Android der nächsten M-Serie braucht, bringt das Dateisystem Ext 4 eine eingebaute Verschlüsselung [3] mit. Sie ist auf Dateisystemebene umgesetzt, verschlüsselt aber nur Dateien und keine Metadaten. Damit bietet sie keinen vollständigen Ersatz für Luks (Linux Unified Key Setup) oder andere Verschlüsselungsverfahren auf Basis von Containern. Eher ähnelt sie Ecrypt-FS, soll aber speicherschonender arbeiten, weil sie die ver- und entschlüsselten Inhalte nicht im Page Cache vorhält. Inhalte chiffriert Ext 4 dabei nach AES-256-XTS, Dateinamen nach AES-256-CBC.

Btr-FS kann dank neuer Patches große Datenmengen deutlich besser verarbeiten, die Anregung kommt von Facebook. Dort hatten Administratoren beobachtet, dass Schreiboperationen auf Systemen mit mehr als 20 TByte Speicherplatz häufig mehr als 10 Sekunden länger brauchten. Änderungen am Code für den Zwischenspeicher haben das Problem behoben. Außerdem löscht Btr-FS nun Dateien, die mehr als 3 TByte Platz benötigen.

Nicht zuletzt unterstützt das XFS-Dateisystem seit Kernel 4.1 die Option »RENAME_WHITEOUT« und kommt dadurch mit dem Dateisystem-Dienst Overlay-FS zurecht, der anderen Dateisystemen Union Mounts ermöglicht.

Trace-FS und Autosense-Support

Von Facebook-Mitarbeiter Jens Axboe kommen Patches für Multiqueue Block Layer, die seit Version 3.13 in Linux stecken. Sie beschleunigen die Performance beim Zugriff auf SSDs, indem sie das damit verbundene Arbeitspensum auf mehrere CPU-Kerne verteilen. Außerdem unterstützt die Libata-Bibliothek nun die Autosense-Erweiterung für Native Command Queuing (NCQ). Dadurch kann sie die Fehlermeldungen aktueller Festplatten mit Autosense-Support künftig besser interpretieren.

Für die Fehleranalyse im Linux-Kernel können Entwickler jetzt das neue Dateisystem Trace-FS verwenden und auf Debug-FS verzichten. Während auf letzteres potenziell alle Subsysteme zugreifen, was es zu einem Sicherheitsrisiko macht, stellt Trace-FS [4] dafür spezielle Tracepoints bereit. Daneben überwacht es mit Hilfe eigener Funktionen Aufrufe von »mkdir« oder »rmdir« , die Verzeichnisse erstellen und entfernen.

Intel-Grafik für Xen-Gäste

Auch im Grafikbereich tut sich wieder etwas. Der freie Nouveau-Treiber für GPUs von Nvidia generiert jetzt eine eigene Firmware für die Geforce-Serie GTX 750 und extrahiert diese nicht mehr aus dem proprietären Treiber. Der Radeon-Treiber für Grafikkarten von AMD verwendet das für moderne 4-K-Monitore benötigte Protokoll Displayport Multi-Stream Transport (DP MST).

Neben weiteren Codeteilen für Intels Skylake-Plattform kommt der aktuelle i915-Treiber mit virtuellen GPUs klar, die bislang aber nur unter Xen laufen. Gastsysteme können dadurch direkt auf Intels Grafikchips HD und Iris zugreifen. Ein Treiber für die Kernel Virtual Machine (KVM) ist noch in Planung.

Der Code für den neuen AMDGPU-Treiber, der sowohl dem freien Radeon-Treiber als auch dem proprietären Catalyst-Treiber als Basis dienen soll, landet indes noch nicht im Kernel 4.1.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 2 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben