Seite 3: Grafiktreiber von ARM, Prozessor schlafen lassen, Live Patching, …

Inhaltsverzeichnis

Ein Grafiktreiber für ARM-Chip, zwei weitere im Anflug

Die für Prozessorkern-Designs bekannte Firma ARM hat den Grafiktreiber Komeda beigesteuert, der den Mali D71 und dessen Nachfolger unterstützt, wie die Dokumentation erläutert. Das sind "Display Processors", ähnlich wie DP500, DP550 und DP650, die Linux mit dem ebenfalls von ARM zugelieferten Treiber Mali-DP schon länger unterstützt. Die genannten Grafikkerne sind vornehmlich für die Bildausgabe ausgelegt; ihnen fehlt daher eine 3D-Einheit, die bei PC-Grafikchips seit der Jahrtausendwende Usus sind.

3D-Funktionen sind anderen IP-Cores der Mali-Produktpalette vorbehalten, die geläufiger sind und sich auf so manchem Einplatinencomputer finden. Solche Mali-GPU unterstützt Linux nach wie vor nicht von Haus aus. Das sollen die Kernel-Treiber Lima und Panfrost ändern, die zur Aufnahme in Linux 5.2 vorgesehen sind; darauf bauen gleichnamige OpenGL-Treiber zur 3D-Beschleunigung auf, die Mesa 19.1 mitbringen wird. Lima unterstützt dabei "Utgard"-GPUs der 400er-Serie; Panfrost hingegen ist für die neueren "Midgard"- und "Bifrost"-GPUs ausgelegt, die unter den Mali-Modelbezeichnungen T6xx, T7xx, T8xx respektive G3x, G5x, G7x segeln. Bei der Entwicklung dieser Treiber hat ARM allerdings untätig daneben gestanden. Vielmehr entstanden sie weitgehend mit Hilfe von Hardware- und Treiber-Analysen (Reverse Engineering), daher unterstützen beide nur ausgewählte Grafikkerne und längst nicht alle ihrer Funktionen.

Prozessor passend schlafen schicken

Geringeren Stromverbrauch und zugleich bessere Performance verspricht ein "Timer Events Oriented" (TEO) genannter CPUIdle-Governor. Wie der bislang auf vielen Systemen genutzten CPUIdle-Regulator "Menu" entscheidet er bei Untätigkeit darüber, ob und wie tief der Kernel den ganzen Hauptprozessor schlafen schickt, um den Stromverbrauch zu reduzieren. Beide arbeiten sogar mit einer ähnlichen Strategie. Wie der TEO-Entwickler im Commit-Kommentar erläutert, mache der Menu-Governor aber einige fragwürdige Dinge. Das ist indes keine Meinung eines dahergelaufenden Newcomers; wie TEO selbst stammt die Aussage vielmehr vom langjährigen Betreuer des Power-Management-Codes im Kernel, der daher den Code des Menu-Governor gut kennt.

Einer der Hauptunterschiede: TEO verwendet für seine Entscheidungen eine andere Bemessungsgrundlage. Sie soll deutlich besser zur "Tickless"-Arbeitsweise passen, die sich seit Linux 3.10 über die Option CONFIG_NO_HZ_FULL aktivieren lässt, die bei Kernel-Image heutiger Distributionen meist gesetzt ist. Details zu TEO finden sich im Kommentar eines Git-Commits, den darin enthaltenen Dokumentationsänderungen und dem LWN.net-Artikel "Improving idle behavior in tickless systems".

Ob TEO im Einzelfall besser läuft, hängt allerdings stark von den jeweiligen Umgebungsbedingungen ab. Kein Wunder, denn es gibt Software und Workloads, die speziell auf die Arbeitsweise des Menu-Governor abgestimmt sind; das ist auch der Grund, warum das Problem nicht mit inkrementellen Verbesserungen am Menu-Governor angegangen wurde, wie es die Kernel-Entwickler sonst in solchen Situationen tun; der alte Governor wird daher auch weiter im Rahmen des Kernels gewartet.

Neue Wege, den Kernel im Betrieb zu verändern

Beim Kernel Live Patching (KLP), mit dem sich kleinere Kernel-Änderungen (vorwiegend Sicherheitskorrekturen) im Betrieb vornehmen lassen, kann ein Sammel-Patch jetzt alle vorher angewendeten Live-Patches ersetzen. Das ist einem "Atomic Replace" genannten Ansatz zu verdanken, der die Entwicklung solcher "kumulativer Live Patches" erheblich erleichtert; er bringt auch weitere Verbesserungen, die die zugehörige Dokumentation erläutert; weitere Einblicke in die Motivation der verantwortlichen Entwickler liefert der LWN.net-Artikel "Live patching for CPU vulnerabilities".

Endlich: Mehrere Sicherheitsmodule parallel aktivieren

Große Fortschritte gab es bei den seit über fünfzehn Jahren vorangetriebenen Bemühungen, Linux Security Modules (LSMs) wie SELinux, AppArmor, Smack durch "Stacking" parallel zu nutzen. Nachdem das mit einzelnen kleineren LSMs schon klappte, sind jetzt die wesentlichen Vorarbeiten in Linux 5.1 eingeflossen, durch die das bald mit allen LSMs gelingen soll.

Dabei entstand der neue Boot-Parameter lsm=, über den man das oder die aktiven LSMs jetzt beim Systemstart festlegen kann; einen Standardwert lässt sich beim Bau des Kernels über die neue Option CONFIG_LSM vorgeben. Ein Stacking funktioniert bei 5.1 aber nur mit kleineren, wenig bekannten LSMs wie SARA und Landlock; langfristig gelingt es dann aber womöglich, auf einem mit SELinux arbeitenden System vielleicht die Sandbox-Techniken des Paketformats Snap nutzen zu können, das dazu auf AppArmor angewiesen ist.