Kernel-Log – Was 3.17 bringt (2): Infrastruktur

Der Kernel bietet nun Funktionen zur effizienteren Interprozess-Kommunikation. Ein neuer Mechanismus zur Abfrage von Zufallszahlen beseitigt zwei Probleme, die zu schwacher Kryptographie führen können.

1

23.09.2014, 17:41 Uhr

Lesezeit: 12 Min.

c't Magazin

Von

Thorsten Leemhuis

Ab Version 3.17 unterstützt der Linux-Kernel den Funktionsaufruf memfd_create(). Programme können über diesen Syscall einen File Descriptor anlegen, der nicht auf eine Datei im Dateisystem, sondern auf einen anonymen Arbeitsspeicherbereich (anonymous memory) verweist. Durch das ebenfalls neue File Sealing und kann der Kernel einen so erstellten File Descriptor versiegeln, um Änderungen an den darüber referenzierten Speicherbereichen zu unterbinden.

Diese Funktionen wurden vornehmlich für den designierten D-Bus-Nachfolger Kdbus entwickelt. Der neue Dienst zur Interprozesskommunikation (IPC) will sie nutzen, wenn Programme größerer Datenmengen via Kdbus weitergeben. Bislang haben IPC-Dienste die ausgetauschten Daten typischerweise vom Adressraum des sendenden Programms in den des empfangenden Programms kopiert; damit stellen sie sicher, dass der Sender die Daten nicht noch verändert, während der Empfänger sie verarbeitet.

Entwicklungsstand

Mittlerweile gibt es die sechste Vorabversion von Linux 3.17. In dessen Freigabemail deutete Torvalds an, dass er 3.17 vielleicht doch noch am letzten September-Wochenende freigibt. Danach hatte es schon kurz nach der Veröffentlichung des RC4 ausgesehen; beim RC5 schien es dann aber, als wolle er die Fertigstellung bis Mitte Oktober verzögern, damit das Merge Window von 3.18 nicht mit seiner Reise zur LinuxCon Europe in Düsseldorf kollidiert.

Dieser Zeit und Ressourcen kostende Aufwand kann bei Einsatz von Memfd und File Sealing jetzt entfallen, da Kdbus statt der Daten lediglich den versiegelten File Descriptior weiterreichen kann. Diese "Zero-Copy-IPC" vermeidet so den Overhead, der ein Grund ist, warum Gnome und KDE D-Bus vornehmlich zum Austausch kleinerer Datenmengen verwenden.

Memfd und File Sealing sind auch für anderen Dinge nützlich; etwa für die Grafikausgabe mit Wayland. Maßgeblich vonangetrieben wurden die neuen Funktionen von David Herrmann, der sie in einem Blog-Eintrag näher beschreibt. Einen anderen Blick auf die neuen Techniken liefert der LWN.net-Artikel "Sealed files".

Verlässlichere Zufallszahlenlieferung

Programme können jetzt den Funktionsaufruf "getrandom(2)" nutzen, um Zufallszahlen beim Kernel abzurufen. Der neue Syscall vermeidet ein Problem beim Abruf von Zufallszahlen via /dev/random und /dev/urandom, durch das Programme manchmal Zufallszahlen erhalten haben, die zuvor schon ein anderer Prozess erhalten hat. Angreifer können dieses Wissen nutzen, um auf dem System erzeugte Schlüssel zu kompromittieren.

Dieses Verhalten des Linux-Kernels ist bereits seit einer Weile bekannt, daher enthält die von vielen Programmen für Kryptographie-Aufgaben genutzte OpenSSL-Bibliothek einen Workaround, der das Problem abfängt. Der dafür zuständige Code war den Entwicklern der LibreSSL-Bibliothek aber ein Dorn im Auge, da er die Wartung des nach Heartbeat entstandenen OpenSSL-Ablegers verkompliziert. Die Entwickler haben daher die Programmierer des Linux-Kernels gebeten, die Ursache aus der Welt zu schaffen, um den eigenen Code schlank halten zu können. Linux-Urgestein Theodore 'tytso' Ts'o, der das Random-Subsystems des Linux-Kernels pflegt, hat daraufhin den jetzt integrierten Getrandom-Funktionsaufruf geschaffen, der ähnlich funktioniert wie getentropy() von OpenBSD.

Wie beim Lesen von /dev/random kann der neue Funktionsaufruf blockieren, wenn dem Pseudorandom number generator (PRNG) des Kernel keine Entropie mehr zur Verfügung steht. Falls das nicht erwünscht ist, kann der Syscall auch – ähnlich wie beim Lesen aus /dev/urandom – beständig Zufallsdaten liefern. Der Syscall bietet hier aber eine Vorteil, denn beim Setzen eines Flags liefert er erst Zufallszahlen, nachdem der PRNG mit 128 Bit an Entropie initialisiert wurde. Bei x86-Systemen ist das oft schon sehr früh im Boot-Prozess der Fall; bei Embedded-CPUs allerdings manchmal nicht, was zu schwacher Kryptographie führen kann.

ACPI

Der ACPI-Interpreter des Kernels unterstützt nun ACPI 5.1 (u. a. 1, 2, 3, 4, 5). Diese im August veröffentlichte Version hat unter anderem Unterstützung für ARMv8 gebracht, die der Interpreter nun ebenfalls implementiert (u. a. 1, 2, 3). Der ARM64-Code nutzt diese Funktionen allerdings noch nicht, denn die dafür zuständigen Änderungen werden noch diskutiert – recht lebhaft, denn der Einsatz von ACPI für Systemkonfiguration und Power Management auf ARM ist ein Thema, das schon seit längerem für Streitereien sorgt (1, 2).

Bei Windows-8-Notebooks soll die Regelung der Bildschirmhelligkeit nun besser funktionieren. Das ist einer anderen Herangehensweise zu verdanken, die bislang standardmäßig deaktiviert war, weil sie auf manchen Notebook zu Problemen führte. Diese Probleme soll 3.17 nun ausräumen, nachdem die Grundlagen dafür schon bei 3.16 gelegt wurden.

Tracing, Zeitprobleme, Kexec

SVG-Datei von "perf timechart" im I/O-Modus.

Das Trace-Kommando des Performance-Analyse- und Ablaufverfolgungs-Werkzeug perf liefert nun Details zu Pagefaults (1, 2, 3). Das Timechart-Kommando von Perf erzeugt auf Wunsch nun SVG-Dateien, die Storage- und Netzwerk-Aktivitäten von Programmen aufzeigen

Es gibt Anfänge zur Beseitigung des Jahr-2038-Problems, das viele 32-Bit-Unixe plagt (1, 2, 3). NetBSD und OpenBSD haben es in den letzten Jahren bereits behoben. Bis das auch für Linux gilt, sind noch allerlei Fragen zu klären; Details dazu liefert ein LWN.net-Artikel und eine Mail eines Linux-Entwicklers.

Der Kernel kann jetzt selbst einen anderen Kernel in den Speicher laden, um ihn bei Bedarf zu booten; bislang ging das nur mit Hilfe des Userspace-Werkzeugs kexec. (1, 2, 3, 4, 5, 6). Der Kernel kann so im Fall eines kritischen Fehlers einen anderen Kernel starten. Das System ist so schneller wieder einsatzbereit, da dieser Startweg die Initialisierung und den Selbsttest der Firmware umgeht, die bei Servern manchmal mehrere Minuten in Anspruch nehmen.

Das Ende September oder Anfang Oktober erwartete Linux 3.17 befindet sich in der Stabilisierungsphase. Größere Umbauarbeiten gibt es in dieser Zeit nur in seltenen Ausnahmefällen, denn alle wesentlichen Neuerungen haben die Kernel-Hacker bereits Anfang August in den ersten beiden Entwicklungswochen integriert. Das Kernel-Log kann daher bereits vor der Fertigstellung einen Überblick über die wichtigsten Änderungen dieser Version liefern. Das erfolgt im Rahmen der Artikelserie "Was 3.17 bringt", die aus drei Teilen besteht:

Die bisherige Kexec-Methode per Userspace-Tool hebelt eine Eigenschaft von Secure Boot aus, daher haben einige Linux-Distributionen den Einsatz von Kexec unterbunden, wenn sie per Secure Boot gestartet wurden. Durch die Verlagerung der Ladefunktion in den Kernel kann der Kernel nun mit seiner Signatur-Prüfung sicherstellen, das er per Kexec nur vertrauenswürdige Systeme startet. Details hierzu liefert der LWN.net-Artikel "Reworking kexec for signatures".

Architektur-Support

Der Kernel beherrscht nun die kürzlich eingeführten X86-Befehle Xsaves und Xrstors, die einige derzeit entwickelte Intel-Prozessoren unterstützen, um den Status von Supervisor-spezifischen CPU-Funktionen beim Context Switch zu speichern (u. .a 1, 2, 3, 4, 5, 6, 7). Der APIC-Code wurde grundrenoviert, was das Fundament zur Unterstützung zum Hotplug von IOAPICs legt.

Der ARM64-Code erhielt Grundlagen zur Nutzung einer vierstufige Page Translation Table. Mit einer solchen lassen sich 48 Bits zur Speicheradressierung nutzen, mit denen sich theoretisch bis zu 256 TByte Arbeitsspeicher ansprechen lässt; der Code ist aber noch als "kaputt" markiert, weil noch einige anderen Änderungen nötig sind, damit KVM auf ARM64 weiterhin funktioniert.

Der MIPS-Code unterstützt nun den Loongson-3B und NUMA beim Loongson-3.

Linux unterstützt nun POWER3 und RS64 nicht mehr, denn die Kernel-Entwickler haben den Code für POWER-Prozessoren vor dem POWER4 entfernt; dieser hatte bereits in den vorangegangenen Version nicht mehr funktioniert, ohne dass sich jemand beschwert hatte (u. a. 1, 2).

Auch auf Systemen, die das Betriebssystem mittels UEFI-Mechanismen starten, lässt sich nun ein Xen-Dom0-Kernel per EFI starten (1, 2). Ein solcher Betrieb erfordert spezielle Handhabung, weil Linux unter dem Xen-Hypervisor läuft; Linux kann daher nicht direkt, sondern nur über den Hypervisor mit der EFI-Firmware interagieren.

Mehr Sicherheit

Der Kernel kann die Echtheit von Firmware nun prüfen, bevor er diese zur Ausführung an die Hardware übergibt (1, 2, 3). Detail zu den Funktionen sowie den Gefahren, die im Firmware-Code lauern können, liefert ein Artikel bei LWN.net.

Linux verarbeitet nun auch Daten und prüft Signaturen, die den von der RSA definierten Public-Key Cryptography Standard 7 (PKCS#7) nutzen, der RFC 2315 beschreibt (u. a. 1, 2, 3, 4, 5, 6)

Der Kernel kann nun einen Thread starten, um die Daten eines Hardware Random Number Generator (HWRNG) als weitere Entropie-Quelle für die Zufallszahlenerzeugung zu nutzen. Bislang überlassen Distributionen die Einbindung eines HWRNG zumeist einem im Userspace arbeitenden Hintergrunddienst wie rngd aus den Rng-Tools.

Der Seccomp Filters Mechanism, der Syscalls filtert und das Aufsetzen einer Sandbox ermöglicht, erhielt Erweiterungen, damit ein Thread eines Programms nun die Filterregeln für alle Threads setzen darf (u. a. 1, 2, 3) Hintergründe liefert ein LWN.net-Artikel aus der Entwicklungsphase; das Programmierinterface hat sich seitdem aber etwas geändert und wird in einer Man-Page erläutert. Zu den Programmen, die Seccomp-Filter zur Abschottung nutzen, zählen Chromium, Chrome und Systemd.

Der Kernel bringt jetzt einen als Deterministic Random Bit Generator (DRBG) bezeichneten Pseudorandom Number Generator mit, wie ihn der NIST-Standard SP 800-90A definiert.

Merge Commits

Es gab noch hunderte andere Änderungen am Code der beschriebenen Kernel-Bereiche. Informationen zu diesen finden Sie über die folgenden Links, die auf Git-Merge-Commits verweisen, mit denen die wesentlichsten Neuerungen dieser Bereiche in Linux 3.17 eingeflossen sind; die Git-Merge-Kommentare enthalten meist eine Beschreibung, die die wichtigsten Änderungen des jeweiligen Subsystems nennt.

Arch – ARM

Arch – x86

Arch – Various

Infrastruktur

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf dem Twitter-Konto "@kernellog" annonciert. (thl)

[Update 29.09.2014, 10:15]: Kleinere Text-Anpassungen im Abschnitt zu Getrandom. Sie stellen unter anderem klar, dass die Schuld für die doppelte Ausgaben von Zufallszahlen nicht direkt beim Kernel liegt. Zudem betreut Ts'o nicht wie Ursprünglich angegeben das Crypto-Subsystem, sondern das Random-Subsystem. (thl)

Alle Angebote

Newsletter heise-Bot Push Push-Nachrichten

${intro} ${title}