© Lukasz Szczepanski, 123RF

Zwischen dem ersten und dem finalen Release von Linux 5.4 hat sich einiges getan. Neue Sicherheitsfeatures bereichern den Kernel, die Entwickler berichten über den “Fallout” von Spectre und Meltdown sowie Maintainer-Sorgen.

Nach einer einwöchigen Extrarunde gab Linus Torvalds am 24. November 2019 den Linux-Kernel 5.4 frei, der sich nun über Kernel.org und Github [1] herunterladen lässt. Neben den Lockdown-Patches machen auch jene für die Integrity Measurement Architecture (IMA) den Kernel sicherer.

Die Patches aus dem Branch »next-lockdown« stammen unter anderem von Matthew Garrett sowie dem Red-Hat-Entwickler David Howells und sollen die Grenze zwischen PID 0 und dem Kernel stärken. Die großen Distributionen bieten ähnliche Optionen bereits seit ein paar Jahren an, allerdings nicht über den Mainline-Kernel.

Aktiviert der Admin das Lockdown-Feature, sperrt es den Zugang zu mehreren Kernel-Funktionen. Das führt laut den Entwicklern dazu, dass bestimmte Anwendungen, die Low-Level-Zugriffe auf die Hardware oder den Kernel brauchen, unter Umständen nicht mehr wie gewohnt funktionieren. Sie empfehlen, das im Vorfeld zu prüfen.

Den Lockdown-Mechanismus aktiviert der Admin beim Booten über Kernel-Parameter. Es gibt die zwei Varianten »lockdown={integrity|confidentiality}«. Entscheidet sich der Admin für die erste Option, deaktiviert das Kernel-Funktionen, die es unprivilegierten Prozessen außerhalb von Ring 0 erlauben, den laufenden Kernel zu verändern. Wählt er die zweite Option, schaltet das jene Kernel-Features ab, über die Anwender aus dem Userland heraus auf vertrauliche Informationen zum Kernel zugreifen. Statt über Kernel-Bootparameter aktivieren Admins das Lockdown-Feature bei Bedarf auch über »/sys/kernel/security/lockdown«.

Die Patches für Kernel 5.4 sorgen dafür, dass Lockdown nicht mehr, wie ursprünglich angedacht, am EFI-Secure-Boot-Feature hängt. Zudem wird Lockdown neuerdings als Linux-Security-Modul implementiert. Damit lässt sich die Sicherheitsfunktion über ein Regelwerk, einen »locked_down«-LSM-Hook und den Kommandozeilenparameter »lockdown« steuern. Zugleich verzichten die Entwickler auf diesem Wege auf ein implizites Regelwerk im Code selbst.

Erweiterte Integrität

Ebenfalls zur Sicherheit tragen Patches für die Integrity Measurement Architecture (IMA) von Mimi Zohar bei (Abbildung 1). Die IMA misst und bewertet ab Kernel 5.4 nun auch angehängte Dateisignaturen für das Kexec-Kernel-Image und Initramfs. Der Fachbegriff [2] “Messen des Bootvorgangs” beschreibt, wie sich dabei die verschiedenen in den Bootprozess involvierten Komponenten in einer Art Kette gegenseitig absichern, sodass ein Angreifer keine davon manipulieren kann. Sowohl das Kexec-Kernel-Image als auch das Initramfs darf zum Signieren nun die Skripte und Tools verwenden, mit denen Entwickler auch ihre Kernel-Module unterschreiben.

Abbildung 1: Mimi Zohar hält auf dem Linux Security Summit Europe 2018 einen Vortrag über das Integrity-Subsystem im Linux-Kernel. Quelle: Linux-Foundation 2018, CC-BY 2.0

Laut der Commit-Nachricht waren einige Umbauten am Verifizierungscode nötig, damit die IMA die Signaturen über das existierende Framework auswerten kann. Sie erzeugt ein File-Hash, das sie in der IMA-Measurement-Liste verstaut und dann das Trusted Platform Module um dieses Hash erweitert. Ein Vorteil der Umbaumühen: Diese Arbeiten ebnen nun auch den Weg, um weitere Verifizierungsmethoden einzuführen. Dazu zählt etwa »fs-verity«, das einen Abgleich auf Basis einer systemweiten Policy erlaubt.

Linus stiftet Chaos

In bestimmten Situationen versuchten Gnomes Display-Manager GDM und »gnome-session« im frühen Bootprozess bislang vergeblich, über »getrandom()« Zufallswerte von Linux zu beziehen. Zwar zweifelte Linus Torvalds die Notwendigkeit dieser Entropie in der frühen Bootphase an, störte sich aber offenbar auch an der dadurch verlängerten Wartezeit im Bootprozess. Also legte er kurzerhand vor dem Release der ersten Kernel-Vorabversion selbst Hand an den Code von »random.c«.

Die Idee des Kernel-Chefs: aktiv Zufallswerte zu erzeugen, wenn das System noch keine anbietet. Das klappt über den CPU-Cycle-Counter, den die meisten Architekturen mitbringen. So generiert Linux ab Version 5.4 schon früh Entropie, auf die der Userspace dann zurückgreift. Zugleich nahm Torvalds eine Änderung am Code von »inode.c« für das Dateisystem Ext4 zurück, der die entropiebasierte Verzögerung ausgelöst hatte.

Integre Dateisysteme

Eric Biggers lieferte kurz nach dem Release von Kernel 5.3 Patches, die einen »fs-verity«-Support für die Dateisysteme Ext4 und F2FS erlauben. Der Code soll vor allem in zwei Projekten für Android zum Einsatz kommen.

Als Dateisystem-Feature liefert »fs-verity« transparent Merkle-Tree-basierte Hashes, um Read-only-Dateien effizient zu authentifizieren und ihre Integrität zu prüfen. Es ähnelt damit »dm-verity«, das allerdings auf Blockgeräte abzielt. Im Vergleich zum Patchset vom Vorjahr ist es nun laut Biggers wesentlich einfacher, »fs-verity« über das UAPI für eine Datei zu aktivieren. Neben dem Code lieferte der Entwickler auch etwas Dokumentation für das Dateisystem-Subsystem.

Für Ext4 warten noch weitere Ergänzungen. So erlaubt ein neuer Debugging-Helfer Userspace-Anwendern, Informationen über den Status des Extent-Status-Cache zu erhalten. Zugleich haben die Entwickler einen mittlerweile redundanten Workaround für den richtigen Umgang mit falsch kodierten Daten für den Zeitraum vor 1970 entfernt. Einerseits kümmern sich Kernel und E2fsck schon länger um das Problem, andererseits datieren nur wenige Dateien so weit zurück.

Ganz neu an Bord ist der ExFAT-Treiber von Microsoft. Das Unternehmen hatte kürzlich die Spezifikationen dafür veröffentlicht und die mit dem Treiber verbundenen Patente in die Obhut des Open Invention Networks (OIN) übergeben. Im nächsten Schritt soll ExFAT im Linux-Kernel landen. Dafür braucht der Treiber allerdings noch einiges an Politur, weshalb ihn Greg Kroah-Hartman zunächst zur Inspektion im Staging-Subsystem zwischenparkt.

In die andere Richtung, nämlich aus dem Kernel hinaus, wandern die Treiber für »uwb« und »wusb«, die drahtlosen USB-Support auf die Beine stellen sollten. Allerdings gibt es weder Geräte dafür noch erhielt der entsprechende Code in den letzten Jahren Updates. Daher soll er ebenfalls zunächst im Staging-Bereich verweilen, um dann den Kernel komplett zu verlassen – sofern niemand laut schreit.

Device-Mapper-Updates

Änderungen bringt auch der Device Mapper mit: Dessen »verity«-Target überprüft die Integrität von Blockgeräten mithilfe kryptografischer Funktionen. Neu im Köcher ist die Option, die Integrität über die PKCS#7-Signatur des Root-Hash zu testen.

Auch bei »clone« handelt es sich um ein neues Device-Mapper-Target. Es erzeugt eine Eins-zu-eins-Kopie eines nur lesbaren Quellgeräts als beschreibbares lokales Zielgerät. Ein virtuelles Blockgerät lässt dabei alle Daten sofort erscheinen und leitet Lese- und Schreibvorgänge weiter. Das soll es ermöglichen, entfernte, nur lesbare Blockgeräte über verschiedene Netzwerkspeicherprotokolle lokal zu speichern und schnell mit den Daten zu arbeiten.

Der AMDGPU-Kernel-Treiber von David Airlie bringt zwar neuerdings Support für Navi 12 und 14 mit, allerdings gilt zumindest die Unterstützung für Navi 12 noch als experimentell. Entwickler müssen sie im Kernel 5.4 über ein spezielles Flag aktivieren. Ersten Code gibt es zudem für AMDs geplante GPU “Arcturus”. Seine APUs benennt AMD jetzt hingegen nach bekannten Malern: “Renoir” freut sich diesmal über zahlreiche Fixes, auch für “Dali” gibt es jetzt Unterstützung im Kernel.

Bei den anderen Grafikkartentreibern hat sich ebenfalls etwas getan: Intel (»i915«) bringt ersten Support für die Plattform “Tiger Lake” mit; der freie Nvidia-Treiber Nouveau erkennt, wenn PCIe-Kabel nicht angesteckt sind, und verbessert das Farbmanagement für Displays.

Wohl auch aufgrund der Erfahrungen mit Spectre, Meltdown und Co. hat Kernel-Entwickler Thomas Gleixner zudem Regeln für den künftigen Umgang mit Security-Zwischenfällen formuliert [3]. Über verschlüsselte Mailinglisten sollen potenzielle Ansprechpartner aus der Kernel-Community und der Industrie in Kontakt miteinander treten.

Lehren aus Spectre und Meltdown

Die zahlreichen Nachfolgelücken von Spectre und Meltdown, darunter RIDL, Fallout und Zombieload, halten die Linux-Entwickler weiter in Atem. Wie, das erläuterte Greg Kroah-Hartman in seiner Keynote auf dem Open Source Summit Europe [4]. Er betonte, dass es sich bei all diesen Lücken um reine Hardware-Bugs handelt, die im Gegensatz zu Spectre und Meltdown selbst nur Intel-Chips betreffen.

Dank dieser Bugs wisse er nun mehr über CPU-Interna, als er jemals habe wissen wollen. Der Betreuer des stabilen Kernel gab dabei dem Open-BSD-Projekt im Nachhinein Recht: Das hatte entschieden, Hyperthreading komplett abzuschalten und die resultierenden Leistungseinbußen zu akzeptieren. Die Sicherheit über die Performance zu stellen, sei laut Kroah-Hartman die richtige Entscheidung gewesen. Er empfehle auch Linux-Admins, im Zweifel das Hyperthreading zu deaktivieren.

Im Interview mit dem Linux-Magazin [5] ergänzten Kroah-Hartman und der für die Kernel-Dokumentation verantwortliche Jonathan Corbet die Ausführungen noch weiter (Abbildung 2). Der ungewollte Blick hinter die CPU-Kulissen bringt laut Corbet die typischen Probleme proprietärer Systeme zum Vorschein. Dazu gehörten unter anderem eine Menge seltsam eingebauter Hardware-Caches, die nun Teil des Übels seien. Die Probleme ließen sich auch deshalb so schwer beheben, weil Process Sharing tief in der Hardware verankert sei.

Abbildung 2: Jonathan Corbet (links) und Greg Kroah-Hartman auf dem Open Source Summit Europe 2019 in Lyon.

Ob sich die Situation mit Hyperthreading irgendwann wieder entspannen werde, lautete eine weitere Frage. Hier sieht Corbet durchaus Bewegung. So arbeiten die Entwickler an neue Features, um Multithreading auch in unsicheren Umgebungen sicherer zu machen. Die Technologie sei kompliziert, als Stichwort nannte er Core Scheduling [6]. Komplett entspannen dürfte sich die Situation aber erst mit einer neuen Generation an Intel-Hardware, die dann aber vermutlich wieder neue Probleme mit sich bringe.

Kernel-Nachwuchs

Neben der Hardware-Security gibt es für die Kernel-Entwickler aber noch eine andere Baustelle: den Nachwuchs. Das bezieht sich nicht auf die regulären Kernel-Entwickler; laut Corbet und Kroah-Hartman gibt es genügend Menschen, die Code für den Kernel produzieren.

Das Problem sei vielmehr – weiterhin – die hohe Bürde für Maintainer. Um viele Subsysteme kümmere sich nur eine einzelne Person, der Busfaktor liege hier relativ hoch. Zudem seien Maintainer chronisch überarbeitet. Einige würden zudem von ihren Arbeitgebern für das Betreuen der Subsysteme nicht bezahlt – selbst dann nicht, wenn die von der Arbeit profitieren.

Beim Entlasten der Maintainer könnten unter anderem angedachte Workflow-Optimierungen helfen. Wer seinen Code aktuell nach den Regeln für Subsystem A schreibt, muss für Subsystem B wieder umlernen, will er auch dort Code unterbringen. Im Laufe der Jahre seien so laut Kroah-Hartman viele kleine Silos entstanden. Die Kernel-Entwickler wollen den Ist-Zustand ans Licht bringen, dokumentieren und so helfen, diese Subsysteme und ihre Workflows zu vereinheitlichen.

Betreuerwechsel beim Raspberry-Pi-Code

Stefan Wahren dürfte das wohl nicht mehr umstimmen: Der Maintainer des Kernel-Codes für die Raspberry-Pi-CPUs wirft Ende 2019 das Handtuch. Ihm fehle neben seinem Hauptjob einfach die nötige Zeit. Auch eine Bezahlung hätte an seinem Rücktritt nichts geändert: Seine Arbeit sei eher ein Hobby gewesen.

Auch Wahrens Co-Maintainer Eric Anholt ließ sich aus der Maintainer-Liste streichen, er sei ebenfalls nicht mehr in der Entwicklung aktiv. Zum Glück gibt es mit Nicolas Saenz Julienne bereits einen Nachfolger, wenn auch nur einen. Da bleibt nur zu hoffen, dass er trotz der Maintainer-Belastungen die Raspberry-Pi-Fahne lange hochhält.