Kernel-Log – Was 3.7 bringt (5): CPU- und Plattform-Code

Inhaltsverzeichnis

Nach der Freigabe-Mail von Linux 3.7-rc6 deutete vieles auf eine Veröffentlichung von Linux 3.7 rund um den ersten Advent hin. In der Mail zur siebten Vorabversion klang es dann allerdings ein wenig so, als gäbe es vielleicht doch noch einen weiteren RC. Ein solcher vertagt die Fertigstellung einer Version typischerweise um eine Woche; weitere Verzögerungen dürfte es aber wohl nur geben, wenn die Kernel-Entwickler zur Fehlerbeseitigung noch umfangreichere Änderungen vornehmen müssen, die eine längere Testphase erfordern.

Die folgende Beschreibung zu den Neuerungen an Prozessor- und Plattform-Code schließt daher nun die Kernel-Log-Mini-Serie "Was 3.7 bringt" ab. Die ersten vier Teile der Serie hatten sich den für Linux 3.7 integrierten Änderungen gewidmet, die die Kernel-Entwickler in den Bereichen Dateisysteme und Storage, Netzwerk, Infrastruktur sowie Treiber vorgenommen haben.

64-Bit-ARM

Der Linux-Kernel unterstützt nun den 64-Bit-ARM-Befehlssatz (u. a. 1, 2, 3, 4). Der Code für den offiziell AArch64 genannte Befehlssatz wurde größtenteils von ARM-Mitarbeitern entwickelt und landete im Verzeichnis arch/arm64/ der Kernel-Quellen, wie es einige Kernel-Entwickler bei der ersten Vorstellung des Codes gefordert hatten. Dadurch ist der Code unabhängig von jenem für 32-Bit-ARM.

Solch eine Trennung hatte es zunächst auch bei den 32- und 64-Bit-Unterstützung für x86- und Power-Prozessoren gegeben; später wurden die 32- und 64-Bit-Verzeichnisse dann bei beiden Architekturen zusammengelegt. Einige Entwickler hatten ein Trennung von 32- und 64-Bit-ARM-Code daher in Frage gestellt; sie wurde letztlich aber doch umgesetzt, weil einige führenden Entwickler des ARM-Codes das für den besten Ansatz hielten. Auch Torvalds sieht die Trennung eher kritisch, wie ein schnippischer Kommentar in der Freigabe-Mail zur ersten Vorabversion von Linux 3.7 zeigt.

Bei der Maschinenabfrage mit uname(2) meldet der Kernel nicht ARM64, sondern das sperrige AArch64, weil einige Programme zur Unterstützung des 64-Bit-ARM-Befehlssatzes diese erwartet. Dazu gehören die Binutils, die AArch64 seit Version 2.23.51.0.2 unterstützen; die Glibc beherrscht AArch64 mit der anstehenden Version 2.17. Auch in den Hauptentwicklungszweig der GCC ist AArch64-Unterstützung eingeflossen; sie soll Bestandteil der GCC 4.8 werden.

Der 64-Bit-taugliche ARM-Befehlssatz wurde im Herbst 2011 mit der ARMv8-Mikroarchitektur angekündigt; die ersten 64-Bit-Prozessorkerne Cortex-A53 und -A57 hat ARM kürzlich vorgestellt. Eine Reihe von Unternehmen will die Kerne einsetzen; AppliedMicro hat einen ARMv8-Kern bereits in einem FPGA implementiert und versprochen, noch vor Jahresende könnten die ersten X-Gene-Chips starten. Die Firma arbeitet zusammen mit ARM und Red Hat an einer Server-Distribution mit ARM64-Linux; die Technik dafür treibt auch eine Arbeitsgruppe von Linaro voran, an der diese drei und einige weitere Unternehmen beteiligt sind.

ARM-Multiplatform

Kurzfristig für ARM-Linux noch viel wichtiger als die 64-Bit-ARM-Unterstützung ist der für Linux 3.7 aufgenommene Multiplatform Support. Damit lässt sich nun ein Kernel-Image erzeugen, das auf verschiedenen 32-Bit-ARM-Plattformen arbeitet. Solch ein Kernel-Image unterstützt bei 3.7 Highbank, Mvebu, Picoxcell, Socfpga und Vexpress; bei späteren Kernel-Versionen soll weiterer Plattform-Code konvertiert werden, damit ein Kernel-Image auf möglichst vielen verschiedenen ARM-Plattformen arbeitet, wie es in der x86-PC-Welt normal ist.

Die Multiplattfom-Unterstützung ist eines der Ziele der zahlreichen Aufräumarbeiten und Umbauten, welche die Linux-ARM-Entwickler schon seit einer Weile durchführen. Hintergründe zu diesem Vorhaben liefern der Artikel "Supporting multi-platform ARM kernels" auf LWN.net und die Videoaufzeichnung eines Vortrags von Linaro-Entwickler Arnd Bergmann, der ab Zeitcode 26:15 auf den Multiplatform Support eingeht.

Die Kernel-Entwickler haben zudem Unterstützung für den Broadcom BCM2835 in Linux integriert (u.a. 1, 2, 3, 4) – ein mit ARM-Kern ausgestatteter SOC (System-on-Chip), der unter anderem den Raspberry Pi antreibt. Die Patches wurden bislang außerhalb des Kernels gepflegt.

Virtualisierung

Zusammen mit Entwicklerversionen des Xen-Hypervisor 4.3 kann Linux jetzt virtuelle Maschinen betreiben, die mit Hilfe der Virtualisierungsfunktionen einiger neuerer ARM-Kerne laufen (u. a. 1, 2). KVM-Unterstützung für die ARM-Virtualisierungsfunktionen ist noch in Vorbereitung.

Über den Key-Value-Pair-Gasttreiber für Microsofts Hyper-V kann ein Linux-Gast nun Informationen zur Netzwerkkonfiguration mit Microsofts Hypervisor austauschen (1, 2). Der Hintergrunddienst hv_kvp_daemon im Tools-Verzeichnis des Linux-Kernels erhielt Erweiterungen zum Austausch solcher Informationen (u. a. 1, 2). Da sich die Schritte zum Setzen und Auslesen der Netzwerkkonfiguration bei den gängigen Linux-Distributionen unterscheiden, greift der Daemon für einige Arbeiten auf Skripte zurück, die sich leicht an die verschiedenen Gegebenheiten anpassen lassen; Beispielskripte zum Konfiguration eines Netzwerkinterfaces oder Auslesen der DNS-Konfiguration stießen ebenfalls zum Kernel.

Über den Parameter "use_bio=1" kann der Virtio-Blockgeräte-Treiber virtio-blk nun einen alternativen Betriebsmodus aktivieren, der bei schnellen Datenträgern den Datenaustausch zwischen Gast und Wirt beschleunigen kann. Das zeigen Messwerte des Entwicklers im Commit-Kommentar, die mit einer Ramdisk und einer PCIe-Flash-Karte von Fusion IO erzeugt wurden; mit einem SATA-Datenträger ist der neue Ansatz allerdings langsamer. Einige weitere wichtige Änderungen im Bereich Virtualisierung erläutern die Mails mit den Haupt-Git-Pull-Request für den KVM-Code von Linux und die Unterstützung von Xen.

Tracing

Zur Tracing-Infrastruktur stieß das Events-Analye-Werkzeug "perf kvm", mit dem sich unter anderem auswerten lässt, wie häufig und aus welchen Gründen von einem KVM-Gast in das Wirtsystem gewechselt wurde ("VM-EXIT").

Das ist aber nur eine von vielen Verbesserungen am Tracing-Code. Neu ist etwa auch das systemweite Tracing-Tool "perf trace". Dessen Entwickler vergleicht den initialen Funktionsumfang im Commit-Kommentar grob mit dem "ehrwürdigen" Werkzeug strace; das neue Werkzeug setze aber auf die Perf-Infrastuktur des Kernels und solle dadurch weitere Funktionen ermöglichen.

Die Kernel Probes (Kprobes) können nun statische Ftrace-Prüfpunkte statt Breakpoints nutzen, wenn es diese an der untersuchten Stelle gibt; das soll den Analyse-Overhead reduzieren. Ebenfalls neu ist Basis-Unterstützung in Perf für die PMU (Performance Monitoring Unit) von Intels Coprozessor Xeon Phi.

Abschottung

Der Linux-Kernel unterstützt nun die Prozessor-Sicherheitsfunktion SMAP (Supervisor Mode Access Prevention) (u.a. 1, 2, 3, 4). Intel will diese Technik mit den Haswell-Prozessoren einführen, die offenbar ab dem ersten Halbjahr 2013 die aktuelle Ivy-Bridge-Generation ablösen sollen. SMAP soll den Speicherbereich von Programmen vor ungewollten Änderungen durch den Kernel schützen; über Kernel-Bugs erzeugen Angreifer solche Speicheränderungen manchmal in Programmen, die mit Root-Rechten laufen, um sich darüber höhere Rechte zu verschaffen. Details zur Technik liefern Intels Architecture Instruction Set Extensions Programming Reference ab Seite 408, ein Beitrag im Grsecurity-Forum und der Artikel "Supervisor Mode Access Protection".

Verschiedenes

Wie bei den meisten der im letzten Jahr veröffentlichten Linux-Versionen haben die Kernel-Entwickler auch für Linux 3.7 einige Krypto-Algorithmen des Kernels optimiert. Durch Verbesserungen am Treiber aesni_intel etwa sollen bestimmte Operationen dreimal so hohen Durchsatz erzielen, wie der Entwickler mit Tcrypt-Messwerten im Commit-Kommentar zeigt .

Das dem Kernel beiliegende Userspace-Diagnose-Programm Turbostat bietet nun eine eigene Option, um die Zahl der aufgetretenen SMIs (System Management Interrupts) anzuzeigen; außerdem liefert es jetzt mehr Informationen zur maximal möglichen Turbo-Boost-Frequenz.

Wenn die ACPI-Tabelle eine Beschreibung für die Komponenten eines Systems enthält, lassen sich diese nun in den Sysfs-Verzeichnissen der jeweiligen Komponente über die Datei firmware_node/description auslesen.

Im Verzeichniss tools/power/acpi/ der Kernel-Quellen finde sich nun das Userspace-Diagnose-Werkzeug acpidump, das die ACPI-Tabellen in einer ASCII-Datei speichert; die Informationen können Entwickler die Fehlersuche erleichtern, die keinen Zugriff auf das betroffene System haben.

Der Sparc-Code kann jetzt mit dem Niagara 4 umzugehen.

Der Power- und PowerPC-Code von Linux unterstützt nun Userspace-Tracing mit Uprobes und bei manchen Prozessoren bis zu 64 TByte Speicher; Letzteres wurde aber noch nicht getestet.