Die Webseite “Make Linux fast again” führt Kernel-Optionen auf, die bremsende Schutzfunktionen gegen CPU-Bugs deaktivieren. Lohnt das Risiko?

Bis vor ein paar Jahren betrafen Sicherheitslücken lediglich die Software eines Computers. Linux-Nutzer durften sich in der Regel entspannt zurücklehnen: Über die regulären Software-Updates landeten von den Entwicklern bereitgestellte Fehlerbereinigungen schnell auf dem eigenen Rechner. Dank Open Source und freier Lizenzen waren alle Änderungen gut dokumentiert und leicht nachzuvollziehen. Probleme bereiteten höchstens vom Netz abgehängte und daher nur umständlich zu aktualisierende Rechner.

Anfang 2018 überrollten Spectre [1] und Meltdown [2] die Computerwelt. Zusätzlich zu ihren schnöden CVE-Nummern erhielten die zwei Super-Bugs furchteinflößende Namen, die es selbst in die 20-Uhr-Nachrichten schafften [3]. Das Problem: Die Schwachstellen betreffen nicht die Software, sondern die in Millionen-Stückzahlen verbauten Prozessoren der ARM-, PowerPC- und x86-Architekturen von Intel und AMD. Betroffen sind somit nicht nur klassische PCs, sondern auch Smartphones, Tablets und unzählige Embedded Devices.

Spectre, Meltdown und Co.

Zu allem Übel blieb es zudem nicht bei dem Duo aus Spectre und Meltdown. Die CPU-Schwachstellen Foreshadow (“L1 Terminal Fault”) [4], Zombieload (“Microarchitectural Data Sampling”) [5] und Speculative Store Bypass [6] gesellten sich schnell dazu und führten zu ähnlichem hohen medialen Interesse.

Im Gegensatz zu Software-Fehlern lassen sich diese Hardware-Bugs nicht ohne Konsequenzen per Update reparieren. Eigentlich müssten Intel, AMD und andere Prozessorhersteller ihre CPUs überarbeiten und den Käufern “reparierte” Prozessoren liefern. In Anbetracht der damit verbundenen Summen scheinen die CPU-Hersteller allerdings, wie einst viele Bankhäuser, als “too big to fail” zu gelten.

Um nun nicht an der Hardware basteln zu müssen, schoben die Chip-Hersteller die nötigen Änderungen lieber auf die Software ab. Erste Sicherheitsaktualisierungen gegen Spectre und Meltdown landeten nur wenige Tage nach Bekanntwerden der Schwachstellen auf den Rechnern der Linux-Nutzer. Die von den Unternehmen ausgelieferten Patches stopfen zwar die Sicherheitslücken, den Preis dafür zahlt jedoch in Form von Leistungseinbußen der Anwender. Statt die Hardware-Fehler zu korrigieren, stellen die CPU-Hersteller einfach die problematischen Funktionen ab.

Unter dem Motto “Make Linux fast again” fasst eine Webseite [7] die für die Abhilfe gegen Spectre, Meltdown und Co. verantwortlichen Kernel-Parameter [8] zusammen (siehe Tabelle “Make Linux fast again”). Ins System eingebaut, versprechen sie wieder mehr Leistung – auf Kosten der Sicherheit. Im Folgenden sehen wir uns die Parameter näher an, erklären, wie Sie die Kernel-Optionen in eine gängige Linux-Distribution wie Ubuntu integrieren, und prüfen, ob es sich lohnt, das mit diesen Kernel-Parametern verbundene Risiko einzugehen.

Spectre und Meltdown

Aktuelle Linux-Distributionen sollten immun gegen die diversen CPU-Bugs sein. Bei Bedarf überprüfen Sie die Situation auf Ihrem Rechner mit dem Spectre & Meltdown Checker [9].

Das Programm findet sich in den Paketquellen aller gängigen Distributionen, wie etwa Ubuntu ab Version 18.04, Fedora ab Version 26 oder OpenSuse Leap 15.1. Das entsprechende Paket nennt sich immer spectre-meltdown-checker. Nach der Installation rufen Sie das Werkzeug mit dem Kommando sudo spectre-meltdown-checker über ein Terminal auf. Alternativ laden Sie das Skript mit den Kommandos aus Listing 1 aus dem Netz herunter und starten es.

$ wget https://meltdown.ovh -O spectre-meltdown-checker.sh
$ chmod +x spectre-meltdown-checker.sh
$ sudo ./spectre-meltdown-checker.sh

In der Zusammenfassung (SUMMARY) am Ende der Ausgabe sollte der Spectre & Meltdown Checker jede CVE-Nummer (und somit jeden CPU-Bug) grün markieren und mit einem OK melden, dass dieses Problem behoben ist (Abbildung 1).

Abbildung 1: Der Spectre & Meltdown Checker sollte auf aktuell gehaltenen Systemen keine Auffälligkeiten melden.

Genügt Ihnen die schon in der Voreinstellung sehr ausführliche Ausgabe nicht, liefert die an den Aufruf angehängte Option --explain weitere Details zu den einzelnen Prüfungen. Beachten Sie dabei allerdings die im Disclaimer (über die Option --disclaimer) gemachte Erklärung: Der Spectre & Meltdown Checker verspricht keine hundertprozentige Sicherheit beim Erkennen der bekannten Exploits.

Make Linux fast again

Um das System mit den von “Make Linux fast again” (MLFA) vorgeschlagenen Parametern zu starten, müssen Sie die Optionen dem Kernel bereits beim Booten mitgeben. Bei den meisten Distributionen übernimmt dies der Grub-Bootmanager. Je nach Boot-Modus (UEFI oder klassisches BIOS) drücken Sie dazu gleich nach dem Anschalten des Rechners [Esc] oder die Umschalttaste, um ins Menü des Bootmanagers zu gelangen.

Dort wählen Sie mit den Pfeiltasten das fragliche System – im folgenden Beispiel Ubuntu –, und drücken [E] für den integrierten Editor. Darin scrollen Sie mit den Pfeiltasten bis zur Zeile linux /boot/vmlinux-[...] und fügen dann zwischen den bereits angelegten Optionen quiet splash und $vt_handoff die Kernel-Optionen aus Listing 2 ein (Abbildung 2).

noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off

Abbildung 2: Die MLFA-Parameter lassen sich ohne Änderungen am System direkt im Grub-Menü eintragen. Beim nächsten Neustart startet der Rechner wieder mit den sicheren Vorgaben.

Mit der Tastenkombination [Strg]+[X] beziehungsweise mit [F10]+ übernehmen Sie die Änderung und starten umgehend in das System. Alternativ drücken Sie [Esc] und kehren unverrichteter Dinge zurück zum Grub-Menü. Beachten Sie, dass die vorgenommene Änderung nur vorübergehend gilt: Sobald Sie das System neu starten, bootet der Rechner wieder mit den ansonsten fest ins System eingebackenen Abhilfen gegen Spectre und Meltdown.

Das Abtippen der Kernel-Optionen im Grub-Editor ist allerdings schon allein aufgrund der kryptischen Optionen anfällig für Fehler; zudem müssen Sie die Sonderzeichen mit einem englischen Tastaturlayout eingeben. Alternativ öffnen Sie daher mit administrativen Rechten die für Grub zuständige Konfigurationsdatei /etc/default/grub in einem Texteditor.

Ans Ende der mit GRUB_CMDLINE_LINUX_DEFAULT beginnenden Zeile hängen Sie die Optionen aus Listing 2 an (Abbildung 3). Danach schalten Sie die Änderungen mit dem Kommando sudo update-grub scharf. Ab jetzt verwendet das System bei jedem Start automatisch die Anti-Anti-Spectre-Parameter.

Abbildung 3: In die Grub-Konfiguration eingetragen, bleiben die MLFA-Parameter fest im System verankert und überdauern so auch einen Neustart des Rechners.

Der Spectre & Meltdown Checker sollte nach dem nächsten Neustart eine Reihe von rot hinterlegten kritischen Schwachstellen zeigen, abhängig von der im Computer verbauten CPU (Abbildung 4). Zum Deaktivieren der Änderungen öffnen Sie die Datei /etc/default/grub wieder in einem mit administrativen Rechten gestarteten Editor und entfernen die zusätzlich hinzugefügten Optionen, bis auf den Standard quiet splash. Damit Grub die Änderung auch beachtet, aktualisieren Sie dessen Konfiguration erneut mit dem Aufruf von sudo update-grub.

Abbildung 4: Mit den MLFA-Parametern gestartet, fällt das System mit Pauken und Trompeten durch die Prüfung des Spectre & Meltdown Checkers. Wie viele Tests es reißt, hängt von der im Rechner verbauten CPU ab.

Auswirkungen

Im Alltag spürt man wenig von den Auswirkungen der Schutzmaßnahmen gegen Spectre und Meltdown. Auf einem als Bürorechner eingesetzten Computer wirken sich die abgeschalteten CPU-Funktionen nicht merklich auf das Surfen im Web, das Schreiben von Briefen oder das Lesen von E-Mails aus: Jeder auch nur halbwegs aktuelle Rechner bietet dafür Leistung im Überfluss.

Interessant wird es, sobald man tatsächlich die maximale Rechenleistung benötigt. Beispielsweise haben Entwickler in der Regel keine Geduld, länger als nötig auf das Kompilieren eines Programms zu warten. Gamer verzichten beim Spielen eines Ego-Shooters nur mit Zähneknirschen auf wichtige FPS. Und wer viel mit großen Videos hantiert, geduldet sich nur ungern länger, bis der Computer das Video in ein bestimmtes Format konvertiert hat.

Um die Auswirkungen nachzustellen, installieren wir auf einem Testrechner mit einer Intel-CPU vom Typ i5-3470T (3,6 GHz, Quad-Core) ein frisches Ubuntu 19.04. Als zweites Testsystem dient ein Notebook des Typs Dell XPS 15 mit Intel i7-7700HQ (3,8 GHz, Octo-Core) und integrierter HD Graphics 630, das unter Arch Linux mit Kernel 5.1.6 läuft. Die im Laptop verbaute Nvidia-Grafikkarte haben wir deaktiviert.

Als Kompilieraufgabe übersetzen wir den Quellcode des Spiels Extreme Tux Racer [10] in ein lauffähiges Programm. Die ersten Zahlen besänftigen hier schon die Gemüter: Der Zeitunterschied zwischen einem ohne und mit MLFA-Parametern gestarteten System beträgt dabei gerade einmal 1,21 s (2,4 Prozent) auf dem Laptop beziehungsweise 2,17 s (5,2 Prozent) auf dem Ubuntu-Testrechner. Verteilt man den Build-Prozess auf alle Kerne der CPU, reduziert sich die Zeit zum Bauen des Programms merklich, doch der Geschwindigkeitsvorteil der MLFA-Optionen hält sich ebenfalls in Grenzen (siehe Tabelle “Performance-Vergleich”).

Repräsentativ für die Spieler vergleichen wir die Ergebnisse des Valley-Benchmarks der Unigine-Game-Engine [11]. Das Programm gibt es für Linux, Mac OS X sowie Windows; es lässt sich kostenlos aus dem Netz laden. Den Testrechner 1 mit seiner doch recht betagten Intel-GPU als spieletauglich zu bezeichnen, wäre realitätsfern, doch für einen Blick auf die 3D-Rechenleistung genügt das System. Das vom Benchmark gezeichnete Bild dürfte Gamer freuen: Die MLFA-Optionen machen so gut wie keinen Unterschied. Da beim 3D-Rendering der Spiellandschaft hauptsächlich die GPU zum Einsatz kommt, hat die Tempobremse durch die Spectre-Patches kaum Folgen.

Als letztes Fallbeispiel müssen sich die MLFA-Kernel-Optionen beim Umwandeln eines mit dem Smartphone gedrehten MP4-Videos mittels Ffmpeg beweisen. Das im Test verwendete Video ist 11 Sekunden lang, wurde mit einer Auflösung von 2160p gedreht und belegt 67,5 MByte auf dem Massenspeicher. Das dann ins WEBM-Format konvertierte und auf Full-HD herunterskalierte Video benötigt nur noch 390 KByte Platz auf der Festplatte. Im Schnitt ergab sich über drei Durchgänge mit den MLFA-Optionen wieder nur eine marginale Zeitersparnis: Beim Testrechner 1 lag der Vorteil bei 1,21 s (2,3 Prozent), auf dem Testsystem 2 bei 0,71 s (5,5 Prozent).

Much risk, no fun

Die mit Spectre, Meltdown und Co. verbundenen Sicherheitslücken sind nicht von der Hand zu weisen. Ohne die entsprechenden Reparaturen am System kann etwa ein Angreifer durch Zombieload alle aufgerufenen Webadressen verfolgen, selbst wenn man mit der Security-Distribution Tails in einer QEMU-VM und dem Tor-Browser arbeitet [12].

Subjektiv betrachtet hat die Workstation des Autors (mit einem 2,9 GHz schnellen i7-7700T-Prozessor von Intel) im Alltag durch die Schutzmaßnahmen im Kernel nicht spürbar an Geschwindigkeit verloren. Legen Sie also Wert auf sichere Daten, Privatsphäre und ein solides System, dann lassen Sie “Make Linux fast again” bleiben.

Selbst wenn ein Rechner bei Ihnen als schnöder Rechenknecht schuftet, der möglichst schnell und effizient arbeiten muss, lohnt es sich nur im Einzelfall, die MLFA-Kernel-Parameter einzubauen. Die in unserem Test ermittelten Leistungssteigerungen von maximal gut 5 Prozent rechtfertigen die damit einhergehenden Sicherheitseinbußen in keiner Weise. Achten Sie lieber darauf, rechenintensive Aufgaben zu optimieren – etwa, indem Sie beim Kompilieren mehrere Threads verwenden. Auf diese Art reduzieren Sie die Wartezeit schnell auf die Hälfte.