Seite 6: Sicherheit: NSA-Algorithmus, Meltdown-Schutz für 32-Bit-x86 & Spectre v4

Inhaltsverzeichnis

Speck noch dabei, Rauswurf aber absehbar

Auch Linux 4.19 unterstützt den umstrittene Speck. Support für diesen von der NSA entwickelten Verschlüsselungsalgorithmus hatten Google-Entwickler zu Linux 4.17 beigesteuert; bei 4.18 rüsteten sie dann noch Speck-Support in Fscrypt nach, weil sie Speck bei Android nutzen wollten. Noch vor Fertigstellung von 4.18 gaben die Entwickler aber überraschend bekannt, dass Google diese Pläne verworfen hat.

Bereits kurz darauf kursierten Patches, um die Speck-Unterstützung wieder komplett zu entfernen. Diese zogen schließlich am 5. September (und damit nach Ende der heißen Entwicklungsphase von 4.19) in "Linux-Next" ein – den Entwicklerzweig, in dem die Programmierer die Änderungen für die jeweils übernächste Version (zu der Zeit also den Nachfolger von 4.19) aufeinander abstimmen.

Manche Patches ziehen nach einer einige Tage dauernden Testphase in linux-next auch noch in den Hauptentwicklungszweig von Linux (und damit die gerade vorbereitete Version, also 4.19) ein, wenn der jeweils zuständige Subsystementwickler das für angebracht hält. Dazu kam es aber nicht – die Patches werden daher wohl in den Nachfolger von 4.19 einfließen, der wahrscheinlich die Versionsnummer 5.0 bekommt und zum Jahreswechsel erscheinen dürfte. Laut Kennzeichnung soll der Patch aber zurückportiert werden. Daher fliegt Speck womöglich beim Stable-Zweig im Rahmen der 4.19.x-Versionspflege doch noch raus.

Meltdown-Schutz für 32-Bit-x86-Systeme – aber nur manche

Linux 4.19 bringt endlich Maßnahmen, mit der für 32-Bit-x86-Prozessoren (aka x86-32) übersetzte Kernel vor der Prozessorsicherheitslücke "Meltdown" schützen können. Für 64-Bit-x86-CPUs (aka x86-64) übersetzte Linux-Kernel können das schon seit Anfang 2018, als die vornehmlich Intel-CPUs betreffende Lücke bekannt wurde. Das ist der Technik Page Table Isolation (PTI) zu verdanken, die zuerst in Linux 4.15 eingeflossen ist.

Ein Kernel-Entwickler hat PTI im Frühjahr auf die x86-32-Architektur portiert und seine Patches dann mehrfach verbessert, weil er selbst oder andere Entwickler beim Begutachten Verbesserungswürdiges gefunden haben. Das ist kein Wunder, denn für PTI waren größere Umbauten am ohnehin schon komplizierten Code zum Speichermanagement nötig. Das ist einer der Gründe, warum es so lange gedauert hat. Ein anderer: Heute dreht sich in der x86-Welt fast alles um 64-Bit-Prozessoren, daher steht der 32-Bit-Support bei Distributoren, Entwicklern und Testern mittlerweile recht weit unten auf der Prioritätenliste. Vermutlich stünde er sogar noch tiefer, wenn er nicht die ersten zwei Jahrzehnte der Linux-Geschichte im Fokus der Entwicklung gestanden hätte. Schließlich ist Linux für solche Prozessoren entstanden und mit ihnen groß geworden.

Besser 64-Bit-Kernel zum Meltdown-Schutz?

Beim PTI für x86-32-Systeme gibt es indes eine Stolperfalle: Erst während der 4.19-Entwicklung fiel auf, dass der Schutz nur bei Kernel-Images funktioniert, die mit Support für PAE übersetzt wurden. 32-Bit-Distributionen, die ausschließlich auf einen Kernel ohne PAE-Support setzen, werden daher auch in Zukunft nicht vor Meltdown schützen können. Anwender von Linux Mint oder Ubuntu brauchen sich darum aber nicht zu sorgen: Bei deren 32-Bit-x86-Kernel ist die Kernel-Bau-Option "CONFIG_HIGHMEM64G" aktiv, die PAE aktiviert. Einige x86-32-Distributionen liefern auch zwei Kernel aus: Einen mit und einen ohne PAE-Support. Wer einen von Meltdown betroffenen Prozessor nutzt und sich vor der Lücke schützen will, sollte daher den mit PAE verwenden und sicherstellen, dass PTI dort aktiv ist.

Auch Anwender, die eine 32-Bit-x86-Distribution auf Systemen mit 64-Bit-x86-Prozessor einsetzen, sollten aufpassen: Anders als 64-Bit-Kernel kann PTI bei 32-Bit-Kerneln keine Process-Context Identifier" (PCID) nutzen. Dabei handelt es sich um eine Funktion, mit der Linux den Overhead von PTI bei Intel-Prozessoren seit der Haswell-Generation (Core-i-4000 und neuer) erheblich reduzieren kann. Für bestmögliche Performance trotz Meltdown-Schutz sollten Anwender daher eine 64-Bit-Distribution nutzen oder ihr 32-Bit-Userland mit einem 64-Bit-Kernel koppeln. Ein 32-Bit-Linux mit PTI weist mit einer deutlichen Warnung auf diesen Aspekt hin; das kann auch unabhängig davon Interessant sein, denn ein 64-Bit-Kernel bietet auch andere Vorteile.

Gegenmaßnahmen für Spectre v4

Der Entwicklerzweig, in dem Torvalds & Co. den Kernel 4.19 vorbereitet haben, war das erste Linux der Kernel.org-Entwickler, das Gegenmaßnahmen für die Prozessorsicherheitslücke Spectre v4 erhielt. Diese hat Linus Torvalds genau zu der Zeit integriert, als die Entdecker und Intel die Lücke bekannt gegeben haben. Bereits kurz darauf haben die Entwickler dann Schutzfunktionen auf Basis des 4.19er-Codes in die Linux-Kernel 4.18.1, 4.17.15, 4.14.63, 4.9.120 und 4.4.148 zurückportiert. Diese erschienen knapp vierundzwanzig Stunden nach Veröffentlichung der Lücke, die auch als Foreshadow oder L1 Terminal Fault (L1TF) bekannt ist.

Bei all diesen und neueren Linux-Versionen kann man das Verhalten der Gegenmaßnahmen über den neuen Kernel-Parameter l1tf= beeinflussen. Standardmäßig nutzt der Kernel einige Schutztechniken, die es in einer Virtual Machine (VM) laufenden Betriebssysteme unmöglich machen, per L1TF die Speicherinhalte des Hosts auszulesen. Diese Maßnahmen reduzieren die Performance manchen Workloads mit VMs aber um 15 bis 50 Prozent. Wer das beim Einsatz vermeiden will, kann die Gegenmaßnahmen über einen Kernel-Parameter lahmlegen – das kann für Systeme interessant sein, bei denen in den VMs garantiert nur vertrauenswürdige Software läuft.

Zu einem noch größeren Performance-Einbruch führt eine weitere Schutzfunktion, die HyperThreading komplett lahmlegt. Diese Gegenmaßnahme ist allerdings standardmäßig inaktiv, denn sie würde auch Systeme treffen, auf denen gar keine VMs laufen. Ohnehin ist sie vornehmlich für Cloud-Anbieter wichtig, deren Kunden eigene Betriebssysteme oder Kernel in den VMs einsetzen können: Ein Nutzer könnte sonst einen Aspekt der Spectre-v4-Problematik nutzen, um Daten von VMs anderer Kunden abzugreifen, die der gleiche CPU-Kern gerade mit HyperThreading parallel ausführt.

Im Rahmen dieser Anpassungen hat der Kernel den Parameter nosmt gelernt, der HyperThreading deaktiviert. Weitere Hintergründe zum Ganzen finden sich in der heise-online-Meldung zum Linux-Schutz vor der Prozessorlücke L1TF und einem Dokument der Linux-Entwickler.

Spectre v2, Performance-Problem-Vermeidung & neue Schutzfunkton

Als Gegenmaßnahme vor der Prozessorsicherheitslücke Spectre v2 unterstützt der Kernel jetzt die Funktion "Enhanced IBRS". Diese soll laut Intel in zukünftigen Intel-CPUs stecken und umfassender schützen als der derzeit typischerweise verwendete Spectre-v2-Schutz Retpoline.

Über den Kernel-Parameter hardened_usercopy= lässt sich jetzt eine intensivere Prüfung der Regionen beim Datenaustausch zwischen Kernel- und Userspace deaktivieren. Linux 4.8 und neuer unterstützen diese Technik, die in bestimmten Stationen einen größeren Performance-Einfluss hat – laut Commit-Kommentar unter anderem bei der Verarbeitung von UDP-Netzwerkpaketen, bei denen der zuständige Entwickler bei einen Test einen Geschwindigkeitsgewinn von acht Prozent erzielen konnte, indem er Hardened Usercopy deaktivierte.

Eine in Linux 4.19 neue Schutzfunktion soll es Angreifern erschweren, Programme durch Tricks dazu zu bringen, in Dateien oder Named Pipes (FIFOs) zu schreiben, die in beschreibbaren Verzeichnissen mit Sticky-Bit liegen. Die Technik ist aus dem "HARDEN_FIFO" genannten Schutz hervorgegangen, den Openwall schon eine Weile nutzt. Der Commit-Kommentar erwähnt die CVE-Bezeichner von acht in den vergangen Jahren bekannt gewordenen Sicherheitslücken, die die neue Maßnahme hätte unterbinden können. Aus Kompatibilitätsgründen ist sie aber standardmäßig inaktiv und muss über die Sysctl protected_fifos und protected_regular eingeschaltet werden.

Einige weitere wichtige Änderungen rund um Sicherheit nennen die Commit-Kommentaren der wichtigsten Merges in den Subsystemen Audit, Crypto, Integrity, Security, SELinux und TPM.