Original-URL des Artikels: https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html    Veröffentlicht: 12.01.2018 12:33    Kurz-URL: https://glm.io/132125

Updates

Wie man Spectre und Meltdown loswird

Sicherheitslücken in fast allen modernen Prozessoren verunsichern seit der vergangenen Woche Privatanwender und Administratoren. Wir erklären, was Nutzer derzeit unternehmen sollten und wo noch Unklarheit besteht. Dabei konzentrieren wir uns auf Desktop- und Server-Systeme.

Nachdem der erste Schock über die Sicherheitslücken Meltdown und Spectre in modernen Prozessoren überwunden ist, gibt es jetzt allerorten Updates. Dabei herrscht nicht nur bei Nutzern Unsicherheit, sondern auch bei den Herstellern. Selbst die großen Unternehmen beschränken ihre Kommunikation meist auf offizielle Verlautbarungen auf ihrer Webseite. Viele detaillierte Nachfragen werden zurzeit gar nicht beantwortet.

Wir erklären, was passiert ist, welche Patches für Nutzer von Microsoft-, Apple- und Linux-Geräten bereitstehen, welche Probleme es dabei gibt und was Privatanwender und Administratoren tun müssen. Naturgemäß sind für das quelloffene Linux mehr Details über die innere Funktionsweise der aktuellen Patches bekannt als für Windows und MacOS. Wer tiefer einsteigen will, dem sei die Lektüre des Linux-Teils daher grundsätzlich empfohlen, auch wenn er auf ein anderes Betriebssystem setzt.

Was ist passiert?

Grundsätzlich gibt es drei Angriffsszenarien, wobei zwei als Spectre (CVE-2017-5753 und CVE-2017-5715) bezeichnet werden und eines als Meltdown (CVE-2017-5754). Von Meltdown sind alle Intel-CPUs betroffen, außerdem einige 64-Bit-Prozessoren von Apple, die auf Designs von ARM basieren, sowie der Cortex-A75 vom ARM selbst. Ob weitere ARM-Designs betroffen sind, ist derzeit nicht bekannt.

Meltdown ermöglicht einem Angreifer unter bestimmten Bedingungen, den Inhalt des Kernelspeichers auszulesen (Rogue Data Cache Read). Weil sich Kernel und Userspace im Translation Lookaside Buffer (TLB) einen Cache teilen, ist es in speziellen Angriffsszenarien möglich, eigentlich vertrauliche Daten aus dem jeweils anderen Bereich auszulesen. Die Verwendung desselben Caches bietet allerdings enorme Geschwindigkeitsvorteile, weil der Speicher von beiden Kontexten verwendet werden kann, ohne diese zu leeren, das macht sich der Meltdown-Angriff jedoch zunutze. Während eines Vortrags auf der Sicherheitskonferenz Real World Crypto sagte der an der Entdeckung beteiligte Sicherheitsforscher Jann Horn von Googles Project Zero, er sei sich "nicht so sicher", ob gegen Meltdown mit den bestehenden Prozessoren ein effektiver Patch entwickelt werden könne. Diese Aussage gilt nach Angaben von Horn auch für die zweite der Spectre-Sicherheitslücken mit der CVE-Nummer 2017-5715.

Spectre betrifft die Art und Weise, wie Prozessoren versuchen, bestimmte Befehle zu erraten, die in naher Zukunft ausgeführt werden könnten (Speculative Execution). Dabei sollen aktuell nicht genutzte Kapazitäten der CPU verwendet werden, um möglicherweise bald benötigte Informationen bereitzustellen. Das Problem: Dabei können dem Prozessor unter Umständen auch Informationen zur Verfügung gestellt werden, die aus anderen Anwendungskontexten stammen und möglicherweise vertraulich sind. Angreifer können die vorausberechneten Inhalte mit Spectre nutzen, um diese vertraulichen Inhalte auszulesen.

Speculative Execution wird seit 1995 in Prozessoren eingesetzt - erstmals mit dem Pentium Pro. Bereits im ersten Jahr des Einsatzes gab es Warnungen vor möglichen Seitenkanalangriffen auf vertrauliche Informationen. Doch erst ein Trend zu mehr Grundlagenforschung im Bereich IT-Security brachte das Thema ernsthaft auf die Agenda gleich mehrerer parallel arbeitender Forscherteams, die die Ergebnisse ihrer Forschungen unabhängig voneinander, aber zu ähnlichen Zeitpunkten bei Intel, AMD und ARM einreichten. Meltdown ist das Werk von Jann Horn von Google Project Zero, Werner Haas und Thomas Prescher von Cyberus Technology. Daniel Gruss, Moritz Lipp sowie Stefan Mangard und Michael Schwarz haben an Meltdown gearbeitet. An der Entdeckung von Spectre waren Jann Horn, Paul Kocher, Daniel Genkin, Mike Hamburg, Moritz Lipp und Yuval Yarom beteiligt.

Was sollten Windows-Nutzer tun?

Microsoft hat für Windows bereits Patches zur Verfügung gestellt, die eine Ausnutzung der Sicherheitslücke zumindest erschweren sollen. Auch Browser, Grafikkarten-Treiber und andere Betriebssysteme wie MacOS haben bereits Patches bekommen. Diese sind aber in einigen Fällen instabil und können meist nur als erste, schnelle Fixes betrachtet werden.

Die ersten Patches für Windows werden bereits verteilt. Ausgenommen sind derzeit einige AMD-Systeme. Für sie werden die Patches vorübergehend nicht verteilt, weil es mit älteren Athlon-Prozessoren teilweise zu Problemen kam. Ebenfalls zu Problemen können einige Virenscanner führen. Trotzdem sollten Windows-Nutzer diese bereitgestellten Patches unbedingt einspielen und ihre Systeme auf einem aktuellen Stand halten.

Windows-Update macht einige Rechner unbenutzbar

Virenscanner greifen tief in den Kernel von Windows ein, um ihre Arbeit auszuführen. Aus diesem Grund müssen die Programme nach einer Richtlinie von Microsoft selbst bestätigen, dass sie mit den von dem Unternehmen eingeführten Änderungen zurechtkommen. Dazu muss der Registry-Eintrag "Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD" Data="0x00000000"" gesetzt werden.

Sollten Nutzer gar keinen Virenscanner nutzen, was dank des integrierten Windows Defender recht unwahrscheinlich ist, müssen sie den Key ebenfalls selbständig setzen. Da dazu recht tief ins System eingegriffen wird, warnt Microsoft, dass nur erfahrene Nutzer die entsprechenden Schritte selbst durchführen sollten. Allerdings dürften diese wohl auch nicht in der Lage sein, Windows Defender selbst komplett zu entfernen, was sowieso nicht zu empfehlen ist. Ist der Schlüssel nicht gesetzt, bekommen Nutzer gar keine Updates mehr - also auch in den kommenden Monaten und vollkommen unabhängig von Meltdown und Spectre. Eine Liste von Virenscannern zeigt den aktuellen Stand der Kompatibilität (Google Doc).

Microsoft hat in der Vergangenheit immer wieder Antivirenprogramme von Drittherstellern deaktiviert, wenn größere Updates eingespielt wurden. Nach einer Kartellbeschwerde von Kaspersky gab das Unternehmen diese Policy aber auf und kündigte an, künftig enger mit den Herstellern zusammenzuarbeiten.

Welche Probleme bereitet das Update?

Nicht nur Antivirenprodukte verursachen Probleme. Auf mehreren Rechnern in der Redaktion konnten wir nach der Installation der Patches Probleme feststellen, da der grundlegende Eingriff in das Speichermanagement in Zusammenarbeit mit dem Prozessor offenbar teilweise zu Inkompatibilitäten führt.

Auf einem Redaktionsrechner funktionierten Peripheriegeräte nicht mehr zuverlässig und Programme stürzten unvermittelt ab. Nach einem Rollback des Updates lief alles wieder problemlos. Eine dauerhaft befriedigende Lösung ist das aber natürlich nicht. Auf einem anderen Rechner hatten insbesondere Browser Probleme, wieder andere Rechner laufen mit den Updates ohne Probleme. Wer große und vor allem homogene Rechnerflotten verwaltet, sollte die Updates vorher an einem Gerät evaluieren.

Doch was genau hat Microsoft eigentlich gepatcht?

Wie Microsofts Meltdown-Patch funktioniert, ist geheim

Zu den konkreten Inhalten der Patches schweigt Microsoft sich aus. Vermutlich wird der TLB jetzt nicht mehr synchron von Kernel und Userspace-Anwendungen bespielt, sondern immer nacheinander. Das führt zu Performance-Einbußen, vor allem, wenn häufige I/O-Operationen oder Kontextwechsel zwischen Kernel und Anwendungen durchgeführt werden.

Nutzer können selbst überprüfen, ob die Updates und der Mikrocode bereits eingespielt wurden. Microsoft hat dazu ein Powershell-Tool bereitgestellt. Die direkte Installation über Powershell hat für uns nicht funktioniert, ein manueller Download des Archivs führte aber zum Ziel. Die Ausgabe zeigt dann an, ob bereits aktueller Mikrocode für die CPU geladen wurde und die Microsoft-Patches installiert sind. Die Bezeichnungen der einzelnen Kategorien erscheinen uns nicht immer glücklich gewählt. So heißt es im Fenster nur kurz "BTI-Hardware present" - dahinter erscheint dann der Wert True oder False. Tatsächlich gemeint ist aber die Frage, ob die verbaute CPU bereits über Mitigationen gegen die zweite Spectre-Lücke ausgestattet wurde, also ein Mikrocode-Update erhalten hat. Komplett ausformuliert sollte es also heißen: "Hardware mit Verwundbarkeit für Branch Tree Injection mit Mitigationen gegen Spectre präsent - ja oder nein".

Kein einheitliches Bild beim Performance-Verlust

Noch bevor wichtige Details über die Sicherheitslücken bekannt waren, spekulierten diverse Medienberichte über die möglichen Auswirkungen der Patches. Bis zu 30 Prozent langsamer sollten die Chips künftig rechnen. Erst Benchmarks zeigen: So dramatisch wird es für die meisten Anwender nicht. Allerdings gilt für Windows-Nutzer, dass die Auswirkungen der Patches auf die Performance steigen, je älter der Chip und die verwendete Windows-Version ist.

Wer also einen Haswell-Prozessor unter Windows 7 nutzt, der soll nach Angaben von Microsofts Windows-Chef Terry Myerson durchaus "spürbare" Performanceverluste haben, wohingegen die Auswirkungen im normalen Einsatz bei Core-i-Chips der aktuellen Serien im Zusammenspiel mit Windows 10 im Alltagsbetrieb nicht spürbar sein sollen. Der Performanceverlust soll in diesem Fall "im einstelligen Prozentbereich" liegen.

Microsofts Server-Betriebssysteme sollen "auf allen Halbleitern" deutliche Einbußen in der Performance haben, wenn "die Mitigationen aktivert sind, um unvertrauten Code auf dem eigenen Server zu isolieren." Nutzer sollten daher für jeden Server genau abwägen, ob sie mehr auf Sicherheit oder auf Performance setzen, sagte Myerson.

Intel selbst hat ebenfalls Benchmarks durchgeführt. So soll der Performance-Verlust bei CPUs der achten und siebten Core-i-Generation bei Office-Benchmarks wie SYSMark2014SE bei rund sechs Prozent liegen, bei CPUs der sechsten Generation mit acht Prozent schon etwas höher.

Generell gilt, dass die Performance nach den Patches vor allem unter I/O-intensiven Operationen leidet. Wer also große Datenbanken betreibt, muss mit deutlich größeren Einschränkungen rechnen. Erste Cloud-Nutzer berichten von zum Teil stark gestiegener Auslastung von ihren Servern.

Wie Windows-Nutzer den Mikrocode bekommen

Die Auswirkungen auf Meltdown können mit Software-Updates in den Betriebssystemen begrenzt werden, für die Variante 2 von Spectre sind aber Microcode-Updates für die CPUs unerlässlich. Viele Hersteller versuchen derzeit, Updates dafür bereitzustellen. Dabei ist die Verunsicherung offenbar groß, auf detaillierte Anfragen bei mehreren Unternehmen haben wir meist noch keine zufriedenstellende Antwort bekommen.

Klar ist: Intel selbst hat zur Mitigation von Spectre in der zweiten Variante, (Branch Target Injection, CVE - 2017-5715) bereits Microcode-Updates entwickelt. Auch AMD stellt optionale Microcode-Updates für Ryzen sowie Epyc bereit und verweist aber darauf, dass ein Angriff über diese Lücke sehr schwer auszunutzen sei. Microcode-Updates für ältere CPU-Modelle will AMD in den kommenden Wochen ausliefern.

Mit dem Microcode steuern CPU-Hersteller die interne Funktionsweise des Prozessors abseits der mit Halbleitern festgelegten Funktionsweisen. Auf einem von uns verwendeten Sony Vaio Pro mit Linux findet sich zum Beispiel aktualisierter Intel-Microcode mit dem Datum 2017-11-20, der gegen Spectre gepatcht ist. Dabei handelt es sich um einen Core i5-4200U auf Haswell-Basis. Intel hat die Updates für Haswell und Broadwell zwischenzeitlich zurückgezogen. Neue Updates werden derzeit getestet und sollen demnächst verteilt werden.

Der Microcode wird nicht dauerhaft auf der CPU abgelegt, sondern jedes Mal beim Start in einen beschreibbaren Speicher (Store) auf dem Chip geladen. Aus diesem Grund wird das Update für Windows-Nutzer auch vom UEFI bereitgestellt und vor dem Boot-Vorgang des Betriebssystems aktiviert.

Intel hat angekündigt, dass 90 Prozent der Chips aus den vergangenen fünf Jahren "innerhalb einer Woche" nach Bekanntwerden der Sicherheitslücken gepatcht würden. Dabei hat der Hersteller das nicht selbst in der Hand.

Denn die entsprechenden Updates hat das Unternehmen den OEM-Herstellern nach eigener Aussage bereits Anfang Dezember zur Verfügung gestellt. Die meisten Hersteller werden den Nutzern die Mikrocode-Updates per Bios-oder UEFI-Update zur Verfügung stellen. Bislang ist kein zuverlässiger Mechanismus bekannt, der ein Update des Microcodes ohne Beteiligung der Bios- oder UEFI-Hersteller ermöglicht.

Grundsätzlich gibt es auch Programme, mit denen Nutzer den Mikrocode selbst aufspielen können. Dies müsste aber nach jedem Start erneut gemacht oder über ein Skript automatisiert werden. Wenn für einen Prozessor neuer Mikrocode von Intel vorliegt, aber kein neues Bios oder UEFI vom Mainboardhersteller oder OEM, könnte dies als Notlösung funktionieren. Für normale Anwender ist dies aber kein empfehlenswerter Weg. Alternativ können Windows-Nutzer ohne Herstellerunterstützung auf eine Linux-Distribution umsteigen.

Auch die Mikrocode-Updates sind nicht perfekt

Intel selbst hat bei einigen der Updates offenbar auch Probleme festgestellt und diese nach Aussage von Lenovo zurückgezogen. Betroffen sind Kaby-Lake- (U/Y, U23e, H/S/X) und Broadwell-Modelle (E). Bei den Kaby-Lake-Chips soll es zu Problemen im Stromsparmodus S3 kommen, die das System anhalten. Bei einigen Broadwell-CPUs hingegen wurden ab und an auftretende Bluescreens während des Startprozesses beobachtet. Wer die Updates bereits installiert hat, soll diese nach Angaben von Intel weiterhin nutzen. Wer dies noch nicht getan hat, soll auf verbesserte Versionen warten.

Ankündigungen gibt es zum Beispiel von Asus und MSI, außerdem von Notebooksherstellern wie Fujitsu und Dell. Der Hersteller MSI hat die Folgen der Veröffentlichungen dabei offenbar nicht vollständig verinnerlicht. In einer Mitteilung schreibt das Unternehmen von "mögliche[n] Sicherheitslücken in der aktuellen Intel-Mikrocode-Version". Spekulativ ist im aktuellen Fall allerdings nicht die Sicherheitslücke, sondern nur die Befehlsausführung der betroffenen Prozessoren.

Dell hat die Updates für zahlreiche Geräte bereits fertig, andere sollen in Kürze folgen. Auch Lenovo hat für zahlreiche Geräte bereits fertige UEFI-Updates, durch die zurückgezogenen Updates von Intel verschiebt sich der Patchzeitraum allerdings teilweise bis Ende Februar. In Lenovos Auflistung fehlen Geräte der X2X-Serien, diese erhalten also offenbar keine Updates.

Surface-Geräte werden direkt von Microsoft ausgestattet

Eine Ausnahme von dieser Regel sind die Surface-Geräte von Microsoft. Diese sollen das Update direkt über Windows-Update erhalten. Damit dürfte die Patchquote bei den Surface-Geräten deutlich höher sein als bei den restlichen PCs.

Denn nicht alle Hersteller bieten eine automatische Überprüfung auf Bios-und UEFI-Updates an. Und selbst wenn Nutzer die Updates angeboten bekommen, dürften viele entweder befürchten, durch die Patches etwas an ihrem Rechner zu zerstören oder die in Rede stehenden Performance-Verluste zu erleiden.

Grundsätzlich sollte Microsoft, ähnlich wie es bei Linux funktioniert, in der Lage sein, aktualisierten Mikrocode während des Bootprozesses zu laden. In einigen Versionen der Server-Betriebssysteme verfährt das Unternehmen auch so. Bislang geschieht dies bei Privatnutzern aber nicht und bisher gab es auch keine wirkliche Notwendigkeit dafür. Ob das Unternehmen sich vorstellen kann, diese Option für Anwender anzubieten, die keine Herstellerunterstützung bekommen, wollte eine Sprecherin auf Nachfrage von Golem.de nicht kommentieren.

Was macht Apple für MacOS-Nutzer?

Auch Apple hat bereits reagiert und Patches für Meltdown bereitgestellt. Da Apple in seinen Mac-Rechnern durchgehend Intel-Chips einsetzt, sind aktuelle Geräte auf jeden Fall von Meltdown betroffen. Und natürlich sind die Chips auch für Spectre anfällig.

Klar ist, dass Nutzer der aktuellen Version 10.13.2 (High Sierra) und wohl auch in der Version 10.13.1 mit Updates für Meltdown versorgt sind. Nutzer der Versionen Sierra (10.12) und El Capitan (10.11) sind derzeit noch nicht bedacht worden, obwohl das in den Release-Notes auch für die älteren Versionen zunächst angekündigt worden war.

Unklar ist, ob der Patch zu einem späteren Zeitraum nachgereicht wird. Wegen zahlreicher Fehler und Probleme in High Sierra dürfte es noch viele Nutzer geben, die aus Unsicherheit eine nicht-aktuelle Version von MacOS verwenden. (Update, 24.01): Apple hat mittlerweile die Vorversionen Sierra und El Capitan gepatcht.

Details zu Spectre-Patches sind bislang unklar

Völlig offen ist bislang noch, wie Apple mit Spectre umgeht. Hier müsste das Unternehmen die von Intel bereitgestellten Mikrocode-Updates einspielen. Da es unter MacOS derzeit offenbar keine praktikable Möglichkeit gibt, den Update-Status der CPU zu checken, berichten Mac-Nutzer, dass sie per Bootcamp eine Windows-Version laden und den Patchstatus dann mit Microsofts Powershell-Tool überprüfen.

Apple hat sich auch auf Anfrage von Golem.de noch nicht geäußert, wann und in welcher Form die Patches für Spectre kommen werden. Ein stabiler Workaround für das Einspielen des Mikrocodes durch Nutzer ist bislang nicht bekannt. Apple-Nutzer sollten darauf achten, die aktuelle Version von MacOS zu benutzen und eventuelle zukünftige Firmware-Updates beachten.

Meltown-Patches für Linux

Nutzer von Linux-Systemen sind für Updates gegen Spectre und Meltdown auf die Kernel-Pakete ihrer Distributionen angewiesen, falls diese nicht auf die Upstream-Versionen von Kernel setzen. Aber selbst hier gibt es einige Unterschiede, die es zu beachten gilt. Bei den Updates gegen Meltdown ist die Sachlage noch vergleichsweise übersichtlich. Die aktuelle Kernel-Version 4.14.13 sowie die noch in Entwicklung befindliche Version 4.15 enthalten die Patches für die sogenannten Kernel Page Table Isolation (KPTI). Die finale Version von Linux 4.15 erscheint vermutlich am 21. Januar.

Diese KPTI-Patches basieren wiederum auf den Kaiser-Patches von den Forschern der TU Graz, die die Meltdown-Lücke gefunden haben. Die Kaiser-Patches sind aber bereits zuvor aus anderen Gründen erstellt worden. Kaiser steht für Kernel Address Isolation to have Side-channels Efficiently Removed und die Arbeiten haben sich als gute Grundlage für Gegenmaßnahmen gegen Meltdown erwiesen.

Kernel- und Userspace besser getrennt

Einige offensichtlich frustrierte Kernel-Hacker hatten zwischenzeitlich auch Fuckwit als Codenamen für die Patchserie vorgeschlagen, das steht für Forcefully Unmap complete Kernel with interrupt Trampolines. Unter Windows wird diese Technik als Kernel Virtual Adress (KVA) Shadow bezeichnet. Das Ziel ist es hierbei, den Adressraum des Kernels möglichst weitgehend von dem einer Userspace-Anwedung zu trennen.

Bisher war der Kernel standardmäßig in den Userspace gemappt, um einen Kontextwechsel zwischen Kernelspace und Userspace schneller durchführen zu können und den Translation Lookaside Buffer (TLB) hierbei nicht leeren zu müssen. Die CPU sorgt eigentlich für die dennoch notwendige strikte Trennung zwischen Kernel- und Userspace, was bei Meltdown allerdings geschickt umgangen wird. Der Kernel wird künftig nicht mehr so gemappt wie bisher, das neue Verhalten führt damit allerdings zwangsläufig zu einem Leistungsverlust und ist genau deshalb auch bisher vermieden worden.

In zwei ausführlichen Texten beschreibt das Magazin LWN.net die Funktionsweise der Patches sowie die langwierigen Iterationen und von den Kernel-Hackern diskutierte Fehler während der Entwicklung. Gesteuert werden kann die Verwendung von PTI mit der Option pti=(yes|no|auto) über die Kommandozeile des Kernels.

Prozess-Kontexte zu Beschleunigung

Damit die Leistungseinbußen zumindest ein wenig abgemildert werden können, nutzen sowohl Windows als auch Linux Process-Context Identifiers (PCID), sofern die Hardware diese unterstützt. Diese sind zwar seit Jahren theoretisch verfügbar, werden aber erst seit Linux 4.14 sinnvoll unterstützt. Die PCID ermöglichen es, Seitentabellen, die im TLB gecacht sind, mit entsprechenden Kennzeichnungen zu markieren.

Das Nachschlagen (Lookup) im TLB wird dann nur für den jeweiligen Kontext erlaubt, wenn der auf der CPU laufende Thread die gleiche Kennzeichnung hat. Die restlichen Einträge im TLB werden schlicht ignoriert. Das vermeidet das Leeren des TLB bei einem Kontextwechsel. Der Entwickler Gil Tene beschreibt diese Funktion in einem Beitrag sehr ausführlich und erläutert mögliche Probleme bei der Verwendung in Gastsystem von virtuellen Maschinen.

Linux-Nutzer finden über /proc/cpufinfo heraus, ob ihr Intel-Chip PCID unterstützt. Das erwähnte Powershell-Skript für Windows listet die Unterstützung für diese Optimierung unter KVAShadowPcidEnabled, Windows nutzt also wohl eine ähnliche Methode wie Linux. Die Versionsvielfalt von Linux hat den Entwicklern die Update-Arbeit aber nicht unbedingt erleichtert.

Angaben zu Leistungseinbußen unter Linux variieren sehr stark je nach eingesetztem Benchmark, Distribution und den genutzten Patches. Red Hat listet etwa Einbußen bis zu 20 Prozent, insbesondere bei der intensiven Nutzung von Datenbanken und bei Anwendungen mit vielen Kontextwechseln vom Kernel- zum Userspace. Das Magazin Phoronix hat darüber hinaus teilweise massive Leistungseinbußen bei I/O-Operationen festgestellt.

Updates für Langzeit-Linux und ARM64

Laut dem Kernel-Maintainer Greg Kroah-Hartman, der unter anderem für die Langzeitpflege verschiedener Kernel zuständig ist, unterschieden sich die Meltdown-Patches für die Version 4.9 und 4.4 jedoch wesentlich von denen der neueren Kernel-Versionen. Das wirkt sich etwa auf damit verbundene Fehler aus. So waren einige Linux-Nutzer davon betroffen, dass ihre Rechner nach dem Einspielen der Meltdown-Patches nicht mehr starteten. Das soll inzwischen aber behoben sein. Die Kernel-Version 3.2 und 3.16 haben ebenfalls bereits Updates bekommen.

Kroah-Hartman verweist in seinem Blog-Eintrag außerdem auf die von den Distributionen gepflegten Kernel-Versionen, die sich teils von den Upstream-Versionen unterscheiden, möglicherweise auch andere Patches gegen Meltdown verwenden als diese und auch anderen Supportintervallen unterliegen. Das gilt etwa für Red Hat mit RHEL 5 (Linux 2.6.18), RHEL 6 (2.6.32) sowie auch RHEL 7 (3.10) sowie für die davon abgeleiteten Distributionen wie CentOS und Scientific Linux.

Suse stellt ebenfalls eine sehr ausführliche Liste mit den bereitgestellten Updates gegen Meltdown zur Verfügung. Die aktuell unterstützten Debian-Versionen nutzen die Upstream-Versionszweige und haben bereits Meltdown-Updates erhalten. Gleiches gilt für Fedora ebenso wie für Ubuntu. Zu beachten ist hier, dass der Support für Ubuntu 17.04 bereits am morgigen Samstag, den 13. Januar, ausläuft und der Kernel hier keine Meltdown-Patches mehr bekommen wird.

Nutzer, die andere speziell angepasste Linux-Distributionen verwenden, etwa auf besonderen Server- oder Storage-Systemen, Switches, sogenannten Middleboxen oder ähnlichem, sollten die jeweiligen Supportseiten der Hardware-Hersteller beachten.

Meltdown-Patches für ARM64

Wie ARM selbst schreibt, ist auch der Cortex-A75 von Meltdown betroffen. Entsprechende KPTI-Patches für die ARM64-Architektur von Linux sind noch nicht stabil, aber bereits in Arbeit. Das Unternehmen ARM empfiehlt das Einspielen der Patches, die per Git verfügbar sind. Diese Patches werden wohl in die Linux-Version 4.16 integriert, die Anfang April erscheinen soll.

Sie werden laut Kroah-Hartman wohl nie als Backport in die Langzeit-Kernel-Versionen 4.4 und 4.9 eingepflegt. Der Maintainer verweist stattdessen auf die Entwicklungszweige der Android-Common-Kernel, in denen die Meltdown-Patches längst integriert seien. Wie viele und vor allem welche Geräte außer Googles Pixel diese Updates aber erreichen werden, ist derzeit noch völlig unklar.

Der Verweis auf Android ist vor allem deshalb wichtig, weil Qualcomms Topmodell für dieses Jahr, der Snapdragon 845, unter anderem den Cortex-A75 nutzt und damit von Meltdown betroffen ist. Der Vorgänger Snapdragon 835 nutzt Cortex-A73-Kerne ebenso wie etwa der Kirin 970 von Huawei, die damit nicht von Meltdown betroffen sind. Der erst vor wenigen Tagen vorgestellte Samsung Exynos 9810 für das kommende Galaxy-S9-Smartphone nutzt laut Hersteller Custom-Cores. Ob und inwieweit diese von den Cortex-A75 abgeleitet sind, ist derzeit ebenso wenig bekannt wie deren Verwundbarkeit für Meltdown.

ARM-CPUs für den Servermarkt gibt es derzeit zwar nur wenige, aber laut einem Bericht des Magazins Networkworld ist etwa der kommende Cavium ThunderX2 für Meltdown verwundbar, das derzeit verfügbare Vorgängermodell jedoch nicht. Zu einer möglichen Meltdown-Lücke in Qualcomms Centriq 2400 mit eigenen Falkor-Kernen äußert sich das Unternehmen bisher nur vage. Zu den APM X-Gene gibt es noch keine Informationen durch den Hersteller.

Meltdown-Variante für weit verbreitete ARM-CPUs

Von einer speziellen Variante von Meltdown sind darüber hinaus laut ARM noch theoretisch die CPUs Cortex-A15, Cortex-A57 und Cortex-A72 betroffen. ARM geht aber bisher davon aus, dass hier Software-Updates nicht notwendig sind, und verweist auf ein eigenes Whitepaper. Auf Github findet sich jedoch inzwischen ein Proof-of-Concept für einen derartigen Angriff auf diese CPUs eines Forschers. Der Meltdown 3a genannte Angriff funktioniere hier verifizierbar für Cortex-A57 und Cortex-A72 und ermögliche das Auslesen beliebiger System-Register aus dem Userspace. Das betreffe insbesondere jene, die nur aus EL1 (Kernel), EL2 (Hypervisor) und EL3 (Secure monitor) erreichbar sein sollten. "Für die Mehrheit der Systemregister ist das Lecken dieser Information aber nicht von wesentlicher Bedeutung", heißt es in dem Whitepaper von ARM dazu.

Davon also möglicherweise betroffen sind folgende auf Cortex-A57 basierende Chips: AMD Opteron A1100, Freescale QorIQ LS20xx, Nvidia Tegra X1, Qualcomm Snapdragon 808 und 810 sowie Samsungs Exynos 7 5433, 7420.

Der Cortex-A72 wird unter anderem in folgenden SoC genutzt: Kirin 950-Serie, Mediateks Helio X2-Serie, Mediateks MT817x, Qualcomms Snapdragon 650-Serie Rockchip RK3399.



Compiler, Linux-Kernel und Mikrocode gegen Spectre

Von den beiden Spectre-Varianten sind auch unter Linux nahezu alle verbreiteten CPU-Architekturen betroffen. Neben den x86-Chips von Intel betrifft das natürlich auch ARM-CPUs, ebenso wie laut IBM die Power-Serien 7,8 und 9 und wohl auch die Z-Serie sowie Fujitsu zufolge auch dessen Sparc-Server-CPUs. Oracle hat mit seinen Januar-Updates ebenfalls bestätigt, dass seine Sparc-v9-CPUs von Spectre betroffen sind. Das meldet das britische Magazin The Register unter Berufung auf ein nichtöffentliches Supportdokument.

Für Variante 1 von Spectre (CVE-2017-5753) werden im Linux-Kernel mit Hilfe der Compiler GCC und LLVM "speculative fences" an betroffenen Code-Stellen eingefügt. Die meisten Distro-Kernel sollten inzwischen über entsprechende Mechanismen verfügen.

Darüber hinaus gibt es weitere Patches, die aktiv gegen diese Spectre-Variante vorgehen sollen, über deren Verwendung aber noch nicht abschließend entschieden ist. Details dazu liefert das Magazin LWN.net.

Mikrocode-Updates als hilfreicher Schritt

Um auch gegen die zweite Variante von Spectre (CVE-2017-5715) geschützt zu sein, sollten Linux-Nutzer auf jeden Fall Mikrocode-Updates für ihre jeweilige Plattform einspielen, sofern diese bereits zur Verfügung stehen.

Intel hat den aktualisierten Mikrocode am 8. Januar veröffentlicht und die meisten Distributionen sollten diesen bereits als Paket bereitstellen. Notwendig wird ein Mikrocode-Update außerdem für die neue Zen-Architektur von AMD. Ob dies Ryzen und Epyc gleichermaßen betrifft, ist derzeit nicht bekannt. Um hier Mikrocode-Updates einspielen zu können, sind einige vorbereitenden Kernel-Patches notwendig, die in den aktuellen Upstream-Kernel bereits verfügbar sind.

Zur Verfügung gestellt wird der AMD-Mikrocode für Zen bereits von Suse, die schreiben, dass damit der Branch Predictor abgeschaltete werde. Das kann wegen der zu erwartenden massiven Leistungseinbußen dabei aber so nicht stimmen. Diese Vermutung hat AMD auch dem US-Magazin Phoronix bestätigt und das Unternehmen arbeite demnach gemeinsam mit Suse an einer besseren Formulierung. AMD selbst beschreibt dieses Update als optional, da die Lücke nur sehr schwer auf den Chips auszunutzen sei.

Debian hat diesen Mikrocode bereits für seinen Unstable-Zweig alias Sid übernommen. Es ist davon auszugehen, dass der AMD-Mikrocode so auch in anderen Debian-Versionen sowie in Ubuntu und darauf basierenden Distributionen landen wird. In der Upstream-Quelle Linux-Firmware von Kernel.org fehlt das Mikrocode-Update von AMD aber noch. Mikrocode-Updates von IBM für Power- und Z-Series-Systeme gibt es direkt vom Hersteller. ARM verweist auf Patches für seine Trusted Firmware, die die SoC- oder Geräte-Hersteller einspielen sollten.

Kernel-Patches zusätzlich zum Mikrocode

Zusätzlich dazu gibt es weitere Umbaumaßnahmen im Linux-Kernel, die teilweise direkt auf den Mikrocode-Funktionen aufbauen, die das Verhalten der CPU in bestimmten Situationen verändern. Die Upstream-Community diskutiert hier aber ebenfalls noch die besten Lösungen und Mechanismen zur Umsetzung. Einige Distro-Kernel nutzen die zur Diskussion stehenden Patches aber bereits.

Das betrifft vor allem die Verwendung von Indirect Branch Restricted Speculation (IBRS) für die x86-Architetur. In der Beschreibung dazu heißt es: "Wenn IBRS gesetzt ist, können Beinahe-Rückgaben- und Beinahe-indirekte-Sprünge/Aufrufe ihre vorhergesagte Zieladresse nicht durch Code steuern, der in einem weniger privilegierten Vorhersagemodus ausgeführt wurde, bevor der IBRS-Modus zuletzt mit dem Wert 1 oder auf einem anderen logischen Prozessor geschrieben wurde, solange alle RSB-Einträge aus dem vorherigen weniger privilegierten Vorhersagemodus überschrieben werden."

Darüber hinaus gibt es noch die Patches für sogenannte Return Trampolines (Retpoline), die LWN.net als eine Attack auf den Branch Predictor nach dem Prinzip des Return-Oriented Programming (ROP) beschreibt. Laut den Initiatoren von Google sollen damit Indirect Branches von der spekulativen Ausführung isoliert werden.

Ob und wann IBRS oder Retpoline oder beide gemeinsam verwendet werden sollten, ist derzeit noch nicht klar. Retpolines funktionieren nach derzeitigem Kenntnisstand aber nicht zuverlässig auf Skylake-CPUs. Auf älteren Intel-CPUs verursachen die IBRS-Patches dagegen teils schwere Leistungseinbußen.

Über dieses Durcheinander beschwert sich Kernel-Maintainer Kroah-Hartman sehr deutlich. So heißt es etwa: "Wir hatten keine wirklichen Informationen darüber, was genau das Spectre-Problem war"; die vielen verschiedenen Patches für die unterschiedlichen Lösungsansätze seien teilweise extrem schlecht gewesen. Eine Koordination wie bei Meltdown über die nicht-öffentliche Security-Liste der Kernel-Hacker hat hier wohl nicht stattgefunden, stattdessen haben vor allem die Enterprise-Distributionen schnell eigene Lösungen umgesetzt. Kroah-Hartman erwartet eine in der Community abgestimmte Lösung für die Probleme mit Spectre in den kommenden Wochen.

Für Linux-Nutzer findet sich auf Github ein Skript, das die jeweilige Nutzung der Patches und Updates auf dem laufenden System analysiert. In den kommenden Wochen sollten Nuzter die zur Verfügung gestellten Updates genau beobachten und einspielen. Wer aktuell kein Tool zur Überprüfung auf Bios-Updates installiert hat sollte das nachholen. Auch wer aktuell bereits Patches eingespielt hat, sollte weiter aufmerksam bleiben. In vielen Fällen sind die aktuellen Fehlerbehebungen wohl erst ein Anfang und dürften langfristig durch stabilere Lösungen ersetzt werden.

Nachtrag vom 18. Januar 2018, 12:40 Uhr

Wir haben den Text um Informationen von Oracle erweitert.

Nachtrag vom 23. Januar 2018, 10:41 Uhr

Wir haben Informationen über die zurückgezogenen Microcode-Updates für Broadwell- und Haswell-Prozessoren ergänzt.

Nachtrag vom 24. Januar 2018, 13:56 Uhr

Apples Meltdown-Patches für MacOS Sierra und El Capitan nachgetragen.  (hg)


Verwandte Artikel:
Fluggastdaten: Regierung dementiert Hackerangriff auf deutsches PNR-System   
(10.03.2018, https://glm.io/133261 )
Sicherheitslücke: Spectre-Angriff kann Intel SGX überwinden   
(07.03.2018, https://glm.io/133209 )
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
Microsoft: KI-Framework kommt auf Windows-10-Endgeräte   
(08.03.2018, https://glm.io/133217 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )

© 1997–2019 Golem.de, https://www.golem.de/