Intel: Designfehler soll für Sicherheitslücke in Prozessoren sorgen, Fix bremst Rechner aus
von caschy | 19 Kommentare
Berichte über einen Designfehler in Intel-Prozessoren machen derzeit die Runde. Schon während der Feiertage war in vielen Mailing-Listen diese Geschichte ein Thema, zwingt dieser Bug aus Sicherheitsgründen doch dazu, dass ein Umschreiben des Kernels des Betriebssystems zu erfolgen hat. Es sollen alle Systeme betroffen sein, die auf Intel x86-Hardware setzen, AMD ist nach jetzigem Stand offenbar nicht betroffen.
Im Linux-Bereich las man schon vor einigen Tagen von einer Überarbeitung des Open-Source-Linux-Kernels und bei Microsoft sind die notwendigen Änderungen wohl schon bei Windows Insidern im Test. Neben den Desktop-Geschichten ist natürlich auch die Cloud betroffen, so werden am 10. Januar Microsoft Azure Virtual Machines einem wichtigem Update unterzogen und auch Google soll betroffen sein.
Das Böse ist nicht nur der Designfehler, der eine Sicherheitslücke aufreißt, sondern auch die Tatsache, dass die Behebungen auf den Plattformen derzeit für drastische Performance-Einbrüche auf betroffenen Intel-Systemen bei bestimmten Aufgaben sorgen können – bis zu 30 Prozent liest man da. Konkrete Details zur Lücke findet man kaum, da sie anscheinend offenbar einem Embargo unterliegen.
Laut Register sind Patches für den Linux-Kernel verfügbar, aber entsprechende Quellcode-Kommentare sollen redigiert worden sein. Diverse Berichte sprechen davon, dass ein Prozess einen Fehler in Intels Hardware ausnutzen kann um zufällig Speicherbereiche zu laden – und eben jenen Prozess die Inhalte ohne Zugriffsüberprüfung zur Verfügung zu stellen.
Die Lösung soll darin bestehen, den Speicher des Kernels komplett von Benutzerprozessen zu trennen. Dies sorgt für getrennte Adressräume, was wiederum dafür sorgt, dass der Prozessor mehr zu tun hat, was zum angesprochenen Verlust von Leistung führen soll. Könnte nun bedeuten, dass alle zeitnah Updates auf den Markt bringen, die das Problem erst einmal beheben – bevor dann die Arbeit an der angezogenen Performanceschraube beginnt.
Bei einem Linux-Kernel 4.14.11 mit PTI-Patches (Config-Option CONFIG_PAGE_TABLE_ISOLATION) wurden von einem Nutzer Benchmarks mit einer PostgreSQL-Datenbank gemacht, hierbei wurden circa 7 Prozent Leistungseinbußen festgestellt und auch hier gibt es eine nette Übersicht. Interessierte Sys-Admins finden bei Reddit eine interessante Diskussion zum Thema.
Sollte sich das alles so bewahrheiten und so schlimm sein, wie beschrieben, dann muss die Geschichte der Benchmarks in den letzten Jahren neu geschrieben werden. Auch die Kommunikation des Fehlers durch Intel dürfte interessant werden.
Wird geladen ...
Ist glaube ich das erste Mal, dass ich hier Wörter nachschlagen muss, da sich mir sonst der Sinn einiger Sätze nicht erschließt (und es nachher noch nicht unbedingt tut).
„Embargo“ und „redigiert“ sind für mich nicht wirklich geläufig und klingen eher nach einer direkten Übersetung vom englischen Quelltext.
Ist wahrscheinlich aber subjektiv.
Zum Fehler selbst: Ich nutze kaum Datenbanken, wo greifen die Performance-Einbußen noch?
@Dr. Richard Wagebauer: praktisch jeder nutzt Datenbanken, da nahezu jedes Programm Datenbanken verwendet.
Einem Doktor sind die beiden Begriffe nicht geläufig? Ghostwriter lässt grüßen?
Verstehe ich das richtig, daß eigentlich ALLE Intel CPUs betroffen sind?
Soweit ich das mitbekommen habe dreht es sich wohl „nur“ umdie intel core cpu`s der letzen beiden Genarationen. Und nur bei Betreibssystemen der X86 fam also 32 bit kernel. Weil diese eben nicht wie die 64 (der auf Grund des größeren Adressraums) einzelne Adressbereiche haben. Inwieweit nun die Lücke auf z.B einem Win64 bit mit 32bit programmen da ist, ist nicht bekannt. Aber ein Win 64bit stellt für alle 32 bit Anwendungen ja nur ein Adressraum im Arbeitsspeicher zur verfügung. Deswegen stürzt ein 32bit Progi ab gehen die meisten andern ja auch mit über den Jordan.
…“Embargo“ und „redigiert“ sind für mich nicht wirklich geläufig… Der gute „Doktor“ hat wohl die Pierre Littbarski Hauptschule besucht.
Michel Ehlert – das klingt für mich sehr nach gefährlichem Halbwissen. Virtuellen Speicher gibt es schon ewig und nicht erst seit 64-bittigen Systemen. Natürlich bekommt daher auch jedes Programm unter Windows seinen eigenen Adressraum. Alles andere wäre sicherheitstechnisch unmöglich umsetzbar. Hast du Quellen für deine Aussage?
Zum Thema: Abwarten und patchen lassen. Ist zwar ärgerlich, aber andere Quellen sprechen wiederum von „nur“ 5% Performanceeinbußen. Wir werden sehen 🙂
Interessant dass ich gestern auf meinem Lenovo x240 ein BIOS/UEFI-Update bekommen habe. Es wird zwar gesagt, dass der Betriebssystemkernel zum fixen geändert werden soll, aber in der Updatebeschreibung findet sich eine CVE, für die scheinbar noch nichts weiteres bekannt ist, CVE-2017-5715. Also entweder versucht es Intel auch darüber oder es ist doch nur zufall und eine andere Sicherheitslücke wurde behoben.
@NickS nein, eher nicht. Das wäre maximal möglich, wenn wirklich der worst case eintreten würde und der sich auch in Zukunft nicht beheben ließe. Aber auch dann wäre es sicher nicht einfach. Schließlich müsste man Intel dann nachweisen, dass sie absichtlich die Geräte langsamer machen. Aber der Fix dürfte eher von den OS Hertsellern kommen, und auch da wäre es Fragwürdig, wie viel man erreichen kann. Aber erstmal wird man eine ganze Weile abwarten müssen.
Das was jetzt in Arbeit ist sind nur Hotfixes die ein Ausnutzen unmöglich machen sollen. Da wird man sehen müssen, wie sich die Leistung tatsächlich verändert. Wenn es nur in Benchmarks messbar sein wird aber keine echte Beeinträchtigung darstellen wird, kannst du’s eh vergessen. Und wenn nicht muss man den OS Herstellern erstmal Zeit geben den Zustand zu verbessern. Bei Windows würde man dann also mindestens bis nach dem nächsten oder übernächsten großen Update warten. Es muss halt eine angemessene Zeit gewährt werden, um plötzlich auftretende Probleme, für die weder MS noch Linux noch macOS wirklich was können, zu beheben
Also ich bin gerade dabei Dr. zu werden und mir ist das Wort „Embargo“ geläufig, alleridngs halte ich es für falsch angewendet. Ein Embargo wird nur von Staaten verhängt… auch wenn Intel mehr Kohle als einige kleine Länder Afrikas besitzt, Embargos werden hier noch nicht verteilt… Dass der gute Herr Dr. Wagenbauer das Wort „redigieren“ nicht kennt, zeugt nicht davon, dass er seine Dissertation hat Korrektur lesen lassen 😛
Ich glaube alle mit AMD Ryzen Systemen werden sich jetzt zufrieden zurücklehnen.
@Krtek sollte es dabei bleiben, dass sich bei denen kein ähnlicher Fehler eingeschlichen hat auf jeden Fall.
Es ist die Rede von 5% bis 30%. Kann mir jemand sagen wer 30% hat?
aber apropos: wo genau ist eigentlich die Rede von 30% verlust? in den obersten beiden Links ist lediglich die Rede von 50% einbußen auf aktuellen AMD CPUs für den Befehl du -s unter Linux. In einem anderen Paper zu der KAISER-Implementierung (wie es Ursprünglich heißen sollte) ist die Rede von 0,28%: https://gruss.cc/files/kaiser.pdf. Es ist aber auch nicht ersichtlich von wann das Paper ist.
Die 30% stammen von Phoronix:
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti
Aktuell wird vermutet, dass die Einbußen umso höher sind, je mehr Syscalls ausgeführt werden müssen. Aber wie gesagt, bisher ist es Vermutung.
@Jan
Das wird nicht vermutet, das ist einfach so. Betreibssysteme haben bisher den kompletten Kernelspeicher in einer Seitentabelle gemappt der auch dem Nutzer zugänglich war. Wenn ein Nutzerprogramm einen Syscall ausführt dann sind diese Tabellen bereits vorhanden und beschleunigen weitere Schritte.
Eigentlich ist das meiste was über dieses Thema zu lesen ist Bullshit. Es handelt sich nicht um einen Designfehler in Intel-Chips. Sondern es gibt mittlerweile mehrere Techniken mit denen man Benutzerseitig die ASLR umgehen kann (Beispiel: https://gruss.cc/files/prefetch.pdf). Darum geht es, und das gilt für alle Platformen inkl. AMD und ARM.
Intel und die anderen haben eine Initiative gestartet um das Problem Industrieweit anzugehen. Die Lösung ist, die Speichertabelle für Nutzer und Kernel komplett zu trennen, so wie das für den eigentlichen Speicher schon lange gemacht wird. Ansatz wird hier erläutert: https://gruss.cc/files/kaiser.pdf
Resultat ist dass Syscalls signifikant ausgebremst werden können. Für Normalanwender dürfte das nicht ins Gewicht fallen (unter 1%). Ausser man ist auf Linux unterwegs (bis 5%). In den letzten macOS und Windows Updates sind die Fixes schon enthalten.
Bitte nicht die ASLR-Geschichte mit dem TLB-Bug bei Intel vermischen.Letzterer wurde beim Beheben von Problemen/Umgehungsversuchen von Ersterem entdeckt.
ASLR kann auf allen Systemem umgangen/ausgehebelt werden, der TLB-Bug ist nur bei Intel vorhanden.
@Kalle Intel CPUs führen Code spekulativ aus, der Zugriff auf Speicherbereiche ermöglicht, die normalerweise höheren Privilegien erfordern. AMD CPUs tun das nicht. Daher ist es ein Hardware Bug. Ansonsten das was Denniss sagt 😉
For reference: https://lkml.org/lkml/2017/12/27/2
@Denniss
Ok, den TSX Bug in Intel Chips habe ich gefunden, da war ich etwas voreilig, lol: http://people.oregonstate.edu/~jangye/assets/papers/2016/jang:drk-bh.pdf
Oder was meinst du mit TLB-Bug? Die Geschichte von vor 10 Jahren mit der ein Jahr zuvor auch AMD zu kämpfen hatte?
Aber wie du schon schreibst ist ASLR generell ein Thema. Unabhängig vom TSX Bug.