Die Neuerungen von Linux 4.12
Seite 7: Debugging via USB, Speicherbandbreiten-Regelung, …
Auf x86-Systemen unterstützt Linux jetzt den "USB3 Debug Port". Über diese via earlyprintk nutzbare Technik lassen sich etwa Informationen zum Boot-Vorgang per USB ausgeben, falls der Kernel abstürzt, bevor andere Ausgabewege (Grafik, Netzwerk, ...) zur Verfügung stehen (u. a. 1, 2).
Linux 4.12 spricht auf x86-64-Systemen nach wie vor bis zu 64 TByte Arbeitsspeicher an. Nach einigen in Linux 4.11 eingeflossenen Vorarbeiten gab es allerdings weitere Umbauten, um auf der 64-Bit-x86-Architektur mithilfe von "5-level paging" bald bis zu 1 Petabyte Arbeitsspeicher adressieren zu können (u. a. 1, 2, 3, 4). Einige das ermöglichende Patches brauchten aber noch Feinschliff, daher wurden diese auf 4.13 vertagt.
Linux unterstützt jetzt Memory Bandwidth Allocation (MBA). Dabei handelt es sich um eine Funktion einiger Server-Prozessoren von Intel, mit der sich die Speicherbandbreite bei der Kommunikation zwischen den Kernen eines Prozessors regeln lässt (u. a. 1, 2, 3)
Die Kernel-Entwickler haben den Support für die 32-Bit-RISC-Architektur AVR32 entfernt. Das soll Wartung und Weiterentwicklung erleichtern. Die AVR32-Prozessoren von Atmel gelten ohnehin als End-of-Life (EOL) und schon bei 4.10 lässt sich der Netzwerk-Code nicht mehr mit dem neuesten Compiler für die Architektur kompilieren; die Entwickler schreiben in der Begründung zum Rauswurf zudem, dass nur noch wenige oder womöglich niemand mehr die Architektur nutze.
Details zu weiteren Änderungen am Architekturcode finden sich in den wichtigsten Merge-Commits der Subsysteme ARC, ARM (u. a. Core, Driver, DT, SoC), ARM64 (Core, SoC, DT), MIPS, NIOS2, PowerPC (1, 2) und S390. Unter diesen Änderungen sind etwa solche, durch die ARM64 nun Kdump (Kernel Crash Dumps) beherrscht. Der PowerPC-Code kann Anwendungen auf Wunsch jetzt einen virtuellen Adressraum von bis zu 512 TByte RAM bereitstellen. Außerdem ist jetzt Code zur Unterstützung des Rockchip RK3288 dabei, der auf dem Asus Tinkerboard sitzt. Auch der im Samsung Chromebook Plus verbaute SoC RK3399 ist neu; Ferner wurde der Support Nvidias Tegra186 (Codename "Parker") verbessert, der auf dem Jetson TX2 sitzt.
Mehr Support für UEFI Secure Boot
Durch einige in den letzten Monaten vorbereitete Umbauten an der Handhabung von Schlüsseln im Keyring des Kernels bietet Linux nun auch einen Blacklist Keyring. Dieser kann Schlüssel nennen, denen der Kernel nicht trauen soll, obwohl sie als vertrauenswürdig eingestufte Signaturen oder Hashes aufweisen. Mit dieser Funktion will der zuständige Entwickler unter anderem Unterstützung für die Blacklist von UEFI Secure Boot realisieren. Dadurch soll die Kexec-Funktion von Linux keine Betriebssysteme mehr starten, deren Start die Rechner-Firmware verweigern würde.
Apropos Secure Boot: Der gleiche Entwickler hat auch einen ganzen Schwung von Patches eingebracht, die Kernel- oder Modul-Parameter kennzeichnen, mit denen sich Hardware-Konfigurationsparameter beeinflussen lassen – beispielsweise die von Treibern verwendeten Ioports, Iomem-Bereiche oder IRQs. Mit solchen Parametern könnte ein Angreifer auf einem per Secure Boot gesicherten System womöglich ein Betriebssystem booten, dessen Start die Sicherheitstechnik normalerweise unterbinden würde. Bei der Secure-Boot-Implementation vieler Distributionen lassen sich diese Parameter daher schon länger nicht beeinflussen, solange die Sicherheitstechnik aktiv ist. Die jetzt integrierten Änderungen legen Grundlagen, durch die sich der offizielle Kernel in Zukunft genauso verhalten soll; Patches, die das umsetzen, sind aber noch in Entwicklung.
Feintuning für die Sicherheit
Kernel Address Space Layout Randomization (KASLR) gilt nun als ausgereift – die Standard-Konfiguration schaltet es daher ein und auch der Hilfetext rät zum Aktivieren. Durch die Technik kann Linux viele der Kernel-intern verwendeten Speicheradressen zerhacken, um Angreifern das Leben zu erschweren. KASLR wurde bei Linux 3.14 eingeführt. Die beiden Hauptentwickler der Sicherheitslösungen Grsecurity und Pax stellten damals allerdings den Nutzen des Ansatzes in Frage; sie KASLR wurde seit dem aber etwas verbessert.
Das neue "Generic TEE Subsystem" ermöglicht einen Austausch mit einem "Trusted Execution Environment" (TEE). Dabei handelt es sich um ein geschütztes Mini-Betriebssystem, das bei manchen ARM-SoCs mithilfe von TrustZone im Hintergrund läuft, wie es ähnlich bei der Management Engine von Intel-Chips der Fall ist. Mit Hilfe eines TEE lässt sich etwa Secure Boot implementieren; es kann aber auch Schlüssel aufnehmen und damit Funktionen zum Digital Rights Management (DRM) übernehmen. Der jetzt aufgenommene Code stellt lediglich die Schnittstellen zum Austausch mit einem TEE bereit; damit einer solcher gelingt ist noch ein Treiber für die TEE-Implementation des jeweiligen SoCs nötig. Details zum TEE-Subsystem liefert ein Artikel bei LWN.net.
Weitere Änderungen rund um die Sicherheit nennen Git-Pull-Kommentare der Subsysteme Audit, Crypto, Security. Unter letzteren ist etwa Unterstützung für TPM Spaces, mit denen sich Zugriffe auf das Trusted Platform Modules isolieren lässt. Ferner gab es eine Detailänderung, die einige Bereiche des APIs für Linux Security Modules (LSM) schreibgeschützt markiert, damit Angreifer diese nicht so leicht für unerwünschte Zwecke missbrauchen können.
