Original-URL des Artikels: https://www.golem.de/news/linux-4-1-ext4-verschluesselt-sich-selbst-1504-113738.html    Veröffentlicht: 27.04.2015 08:27    Kurz-URL: https://glm.io/113738

Linux 4.1

Ext4 verschlüsselt sich selbst

Im nächsten Linux-Kernel 4.1 kann sich das Dateisystem Ext4 selbst verschlüsseln. Die Interprozess-Kommunikation Kernel D-Bus hat es jedoch nach hitziger Diskussion nicht in den aktuellen Kernel geschafft.

Nach der Freigabe von Linux 4.0 vor zwei Wochen hat Linus Torvalds die Testphase der nächsten Version 4.1 des Linux-Kernels eingeläutet. Zu den nennenswerten Änderungen gehört eine integrierte Verschlüsselung im Dateisystem Ext4 und eine erste Unterstützung für ACPI auf der ARM-Plattform. Für Diskussionen sorgte der Antrag, den Kernel D-Bus in Linux 4.1 zu integrieren. Er wurde jedoch abgelehnt.

Der freie Nouveau-Treiber für GPUs von Nvidia generiert eine eigene Firmware für die Geforce-Serie GTX 750 und muss sie nicht mehr aus dem proprietären Treiber extrahieren. Das für moderne 4K-Monitore benötigte Protokoll Displayport Multi-Stream Transport (DP MST) wird jetzt vom Radeon-Treiber für Grafikkarten von AMD unterstützt. Code für den neuen AMDGPU-Treiber, der sowohl für den freien Radeon-Treiber als auch den proprietären Catalyst-Treiber als gemeinsame Basis dienen soll, hat es nicht in den aktuellen Kernel geschafft. Neben weiteren Codeteilen für Intels nächste Skylake-Plattform bringt der aktuelle i915-Treiber die Unterstützung virtueller GPUs mit, die bislang allerdings nur unter Xen laufen. Damit können Gastsysteme direkt auf Intels Grafikchips HD und Iris zugreifen. Ein entsprechender Treiber für die Kernel Virtual Machine (KVM) ist noch in Planung.

Verschlüsseltes Ext4

Weil Google es für sein Android der nächsten M-Serie braucht, gibt es künftig im Dateisystem Ext4 eine integrierte Verschlüsselung. Sie wurde auf Dateisystemebene umgesetzt, verschlüsselt allerdings nur Dateninhalte und beispielsweise noch keine Metadaten. Noch ist es also kein vollständiger Ersatz für LUKs oder andere Verschlüsselungsverfahren auf Basis von Containern. Inhalte werden nach AES-256-XTS und Dateinamen nach AES-256-CBC verschlüsselt, wie ein Dokument verrät.

Für das Dateisystem Btrfs gibt es Patches, die die Verarbeitung großer Datenmengen deutlich verbessern sollen. Bei Facebook hatten Administratoren beobachtet, dass Schreibfunktionen auf Systemen mit mehr als 20 TByte belegtem Speicher sich um zehn Sekunden verzögerten. Mit einigen Änderungen am Code für den Zwischenspeicher soll das Problem jetzt behoben sein. Außerdem lassen sich jetzt Dateien problemlos löschen, die mehr als 3 TByte groß sind. Von Facebooks Jens Axboe kommen auch einige Patches für das Multiqueue Block Layer, das beispielsweise für beschleunigte Zugriffe auf Datenträger sorgt. Außerdem erhielt die Bibliothek für ATA-Laufwerke die Autosense-Erweiterung für Native Command Queuing (NCQ). Libata kann so künftig die Fehlerbehandlung moderner ATA-Laufwerke präziser verarbeiten.

Für die Fehleranalyse im Linux-Kernel können Entwickler jetzt auf das neue Dateisystem TraceFS zugreifen und müssen nicht mehr DebugFS verwenden. Auf DebugFS können sämtliche Subsysteme zugreifen, es stellt so ein potenzielles Sicherheitsproblem dar. Über TraceFS lässt sich hingegen ausschließlich auf Tracingpunkte zugreifen. Außerdem bringt TraceFS eigene Funktionen mit, etwa die Überwachung der Systemaufrufe Mkdir oder Rmdir, mit denen Verzeichnisse erstellt beziehungsweise entfernt werden.

Noch kein Kdbus im Linux-Kernel

Sicherheitsbedenken haben hingegen die Aufnahme des Nachrichtenbus-Systems Kernel D-Bus (KDBus) verhindert. Die Interprozess-Kommunikation ist ein Steckenpferd des Systemd-Entwicklers Lennart Poettering und des Kernel-Entwicklers Greg Kroah-Hartman, der sich einer hitzigen Debatte auf der Mailing-Liste des Linux-Kernels ausgesetzt sah, als er den Code einreichte. Linus Torvalds lehnte die aktuellen KDBus-Patches vor allem deshalb ab, weil darüber Metadaten übertragen werden, die zu viel über das System verraten - etwa, mit welchen Berechtigungen ein Gerät angesprochen wird. Diese Metadaten könnten in der jetzigen Umsetzung einfach protokolliert werden. In der andauernden Diskussion bemängelten weitere Entwickler, dass Kdbus noch nicht genügend überprüft worden sei.

Kroah-Hartman verteidigte indes Kdbus gegen Kritiker, die teils grundsätzlich daran zweifeln. Einige befürworten eine allgemeinere Implementierung einer Interprozess-Kommunikation. Kroah-Hartman erklärte seine Sicht in seinem Kommentar zu den eingereichten Patches: Die aktuelle Umsetzung von D-Bus als Daemon komme nicht mit großen Datenmengen klar und vor allem würden eben jene Metadaten nicht berücksichtigt, die Torvalds kritisierte, etwa Berechtigungen und Zeitstempel. Sie würden aber für eine verbesserte Einbindung von Geräten benötigt. Zudem sei D-Bus aktuell zu langsam, könne erst viel zu spät in der Startphase des Systems initialisiert werden, biete eine nur unzureichende Einbindung in das Sicherheitsframework SELinux und sei ohnehin äußerst fehleranfällig.

An Kdbus wird seit über einem Jahr gearbeitet. Bereits im Oktober 2014 schlug Kroah-Hartman vor, den Code in den Kernel aufzunehmen. Vermutlich gibt es einen weiteren Anlauf in Linux 4.2.

Der Code der Vorabversion des Linux-Kernels 4.1 ist auf kernel.org erhältlich.  (jt)


Verwandte Artikel:
Google: Chromebooks bekommen "Linux-VMs" und "Terminal"   
(27.02.2018, https://glm.io/133030 )
Bpfilter: Linux-Kernel könnte weitere Firewall-Technik bekommen   
(22.02.2018, https://glm.io/132933 )
Systemanalyse: Wie Dtrace auf Linux kommen könnte   
(15.02.2018, https://glm.io/132799 )
Freedreno: Google will Mainline-Linux-Support für Snapdragon 845   
(14.02.2018, https://glm.io/132774 )
Betriebssysteme: Linux 4.16 schließt weitere Spectre- und Meltdown-Lücken   
(13.02.2018, https://glm.io/132729 )

© 1997–2019 Golem.de, https://www.golem.de/