Kernel-Log – Was 3.5 bringt (5): Infrastruktur

Inhaltsverzeichnis

Bei der Freigabe der sechsten Vorabversion hat Linus Torvalds keine Andeutungen zum Veröffentlichungstermin von Linux 3.5 gemacht, aber schon über die Implikationen räsonniert, welche die Urlaubszeit auf die Hauptentwicklungsphase von Linux 3.6 hat. Es ist daher nicht auszuschließen, dass Linux 3.5-rc6 bereits die letzte Vorabversion von Linux 3.5 war und der neue Kernel in Kürze erscheint. Dieser Artikel zu den Änderungen an der Infrastruktur von Linux 3.5 schließt daher die Kernel-Log-Mini-Serie "Was 3.5 bringt" ab.

Die ersten vier Teile der Serie hatten sich den Neuerungen in den Bereichen Netzwerk, Dateisysteme und Storage, Architektur-Code sowie Treibern gewidmet. Im Netzwerk-Bereich gab es indes noch einen erwähnenswerten Nachzügler: In der Stabilisierungsphase stieß eine Erweiterung für den Treiber ipheth zum Kernel, durch die dieser Tethering nicht nur mit vielen iPhones, sondern auch bei iPads mit der USB Product ID 129a beherrscht.

Container

Die maßgeblich von Eric W. Biederman entwickelten "User Namespace Enhancements" zur besseren Abdichtung von Linux Containern sind in Linux 3.5 eingeflossen; der Entwickler beschreibt diese Patch-Sammlung als eine Kurskorrektur für User Namespaces, durch die der Kernel diese nun preiswert, wartbar und weitgehend komplett implementiere.

Die Änderungen sorgen für eine saubere Trennung von User- und Gruppen-IDs zwischen Host und Container. Auch mit Root-Rechten soll man dadurch beispielsweise nicht mehr auf alle Dateien in den Verzeichnissen /proc/ und /sys/ voll zugreifen können; auf diesem Weg konnten Root-Anwender bislang aus Containern heraus das Verhalten des Wirts beeinflussen.

Weitere Hintergründe zum neuen Ansatz liefert ein LWN.net-Artikel. Biederman erläutert in einer Mail, er habe ein unmodifiziertes Debian in einem mit den User Namespace Enhancements gesicherten Container booten können; es sollen aber noch weitere Änderungen am Kernel-Code nötig sein, bis die Funktion so ausgereift ist, dass Distributionskernel sie nutzen können.

Logging

Der Kernel erhielt einige größere Umbauten an den Logging-Funktionen, was Verbesserungen für die zuverlässige Ausgabe und die automatische Analyse von Ereignisprotokollen bieten soll (u. a. 1, 2, 3). So durchlaufen die Ausgaben nun einen Record-Puffer, was ein Vermischen verschiedener Ausgaben vermeiden soll. Ferner tragen sie Meta-Information wie Uhrzeit, Device-Kontext und eine Sequenznummer; dadurch wird es beispielsweise möglich, die Log-Daten nach Vorkommnissen mit bestimmten Devices zu filtern. Details erläutert LWN.net. Anfangs pufferte der neue Ansatz die Ausgaben übermäßig, was zu Problemen führte; die hat der RC5 nun korrigiert.

Funktionslimitierung

Über den "Seccomp Filters Mechanism" kann ein Programm jetzt in der Syntax eines Berkeley Packet Filter (BPF) Filter einrichten, die reglementieren, welche System Calls ein von diesem Programm gestarteter Prozess nutzen darf (u. a.1, 2, 3, 4). Das kann etwa zur weiteren Absicherung im Rahmen von Sandbox-Lösungen interessant sein. Ein Einsatzgebiet von Seccomp ist die Virtualisierung, eines anderes Browser, die nicht vertrauenswürdigen Code ausführen wollen; die Version von Chrome nutzt etwa bei Ubuntu 12.04 Seccomp, um das Flash-Plugin zusätzlich zu sichern. Hintergründe liefern die zugehörige Dokumentation und LWN.net.

Android-Techniken

Linux 3.5 wird die bei Android genutzte "Switch"-Funktion zum Monitoring von Anschlüssen in einer überarbeiteten Form enthalten, die sich "External Connector Class (extcon)" nennt (1, 2).

In das Power-Management-Subsystem ziehen Autosleep und einige zugehörige Erweiterungen ein (1, 2, 3, 4, 5, 6). Durch dieses "Opportunistic Sleep" kann sich ein System selbstständig komplett schlafen legen, wenn es für eine Weile nichts zu tun gibt. Das ist allerdings weniger für Notebooks, sondern eher für Geräte wie Smartphones interessant, die sehr schnell aus dem Tiefschlaf aufwachen; der Android-Kernel bietet im Rahmen von "Wakelocks" alias "Suspend Blockers" schon länger ähnliche Mechanismen und erzielt ohne sie nur dürftige Akku-Laufzeiten. Diese Funktionen waren mehrfach Zankapfel zwischen Entwicklern von Linux und Android; es ist nicht bekannt, ob die Android-Entwickler mittelfristig auf die neue Infrastruktur von Linux umstellen.

Verschiedenes

• Nach langer Entwicklungszeit stieß Frontswap zum Kernel (1, 2, 3, 4, 5). Das Frontend für das Transcendent Memory (TM) des Kernels versucht Speicherbereiche, die sonst auf vergleichsweise langsamere Swap-Devices ausgelagert werden müssten, an die TM-Infrastuktur zu übergeben, damit das die Daten mit einem TM-Backend vielleicht an einer schneller zugänglichen Stelle vorhalten kann – etwa mit Zcache komprimiert im Speicher des jeweiligen Systems oder mit Hilfe von RAMster auf einem anderen System eines Clusters.
• Vornehmlich für den Embedded-Bereich interessant ist der nach langer Entwicklung nun aufgenommene Contiguous Memory Allocator (CMA), durch den der Kernel einige größere und physisch zusammenhängende Speicherbereiche nur noch für verlagerbare Daten nutzt, um Treibern diese Bereiche bei Bedarf für DMA-Aufgaben zur Verfügung zu stellen.
• Mel Gorman und Greg Kroah-Hartman haben die Aufnahmeregeln für Stable-Kernel angepasst, um klarzustellen, unter welchen Umständen auch Änderungen in Stable-Kernel einziehen dürfen, die beispielsweise Performance-Probleme beseitigen, die vieler Anwender betreffen und etwas gefährlicher sind als typische Stable-Patches.