News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

Das ganze wird wohl in einer Rückrufaktion enden. An den Chip wird dann ein weiterer Chip mit der diesmal funktionsfähigen Hardware gelötet, es gibt ein Firmwareupdate und damit hat sich die Sache erledigt.

Rückruf für alle aktuell in Nutzung befindlichen Intel-CPUs? Da wette ich aber dagegen! Zum einen ist ja nicht beliebig viel Platz auf der CPU, um mal eben etwas dazu zu löten, zum anderen ist selbst Intel nicht wohlhabend genug für eine solche Aktion.

Im Endeffekt rechnen die Linux-Entwickler durch PTI mit Performance-Einbußen von rund 5 Prozent, in bestimmten Benchmarks können es aber offenbar auch fast 50 Prozent sein

Zum Vergrößern anklicken....

Am Ende wird diese Geschichte den CPU-Absatz steigern, denn das wäre doch ein echtes Argument für den Neukauf, oder? Klingt irgendwie, als ob Intel von Apple gelernt hätte...

Gruß,
CTN

Kann man das auch mal für nicht IT Menschen erklären?
Das habe ich jetzt verstanden:
Die CPUs haben einen Pufferspeicher (Cache), auf den laufende Programme zugreifen.
Es ist möglich, dass Programme auf Dateien im Cache Zugriff haben, die zu einem anderem Programm gehören?
Die Software Lösung sieht vor, den Pufferspeicher ständig zu löschen, was unter Umständen Leistung kostet.

Ist das so richtig?
Was steht denn im Cache? Da werden wohl kaum ganze geöffnete Excel Dateien drinstecken?
Für einen Laien, was ist hier die "Sicherheit"slücke? Kann man die Dateien verändern und so einen Crash verursachen? Stecken da vollverwertige Dateien drin, die persönliche Daten beinhalten, die ausgespäht werden können?
Für mein Verständnis steckt in einem kleinem Cache innerhalb einer CPU "nur" binäre Artimetik entsprechend dem was das Programm gerade braucht, was jetzt für sich genommen nichts Besonderes oder Schützenwertes wäre?

Ich finde die News irgendwie vom anderen Stern. Im Bezug auf das tägliche Brot hier auf CB, was irgendwie doch ein anderes Clientel anspricht.

Zumal... so wie die Intel-Architekturen aufeinander aufbauen, steckt der Fehler vermutlich sogar in den aktuellen Ice-Lake-ES mit drin, und wäre wohl auch nur durch ein Re-Design zu beheben. Denn wenn man es einfach rausprogrammieren könnte - gäbs wohl auch für die aktuellen Serien schon ein Microcode-Update, statt daß die OS-Programmierer dauerhafte Änderungen einbauen müssen, wie das jetzt passiert.

Also das scheint ein richtig dickes Ding von Intel zu sein!

leipziger1979 schrieb:

Geht es auch objektiver und mit belegbaren Fakten ?
Was diese Halbwahrheiten und "Gerüchte" wieder verursachen sieht man hier an den Kommentaren!

Zum Vergrößern anklicken....

Nein, geht es nicht.

Um welchen Bug es sich genau handelt ist nämlich zu diesem Zeitpunkt gar nicht klar. Nicht weil wir alle so blöd sind und die genauen Details und Fakten nicht nennen wollen, sondern weil sie bisher gar nicht veröffentlicht wurden. In diesem Sinne ist es natürlich richtig, dass viele Dinge hier Spekulation sind und am Ende auch falsch sein könnten. Allerdings muss man sich im Klaren darüber sein, dass das gewählte Vorgehen in diesem Fall* sehr eindeutig auf einen schwerwiegenden Fehler hinweist. Es gibt ausreichend Indizien, die für mich jedenfalls die Spekulationen nur stärken und kaum schwächen.

Wirklich Klarheit um was es genau geht, wird man erst am 4. Jänner um 12 Uhr UTC (also 13 Uhr Mitteleuropäischer Zeit) haben. Bis dahin wird der Bug unter Verschluss gehalten, was nicht nur Entwicklern Zeit gibt, die Sicherheitsmängel zu beheben sondern auch jenen Unternehmen die Erstellung eines Zeitplanes erlaubt, die davon am stärksten betroffen sind.

Gehen wir mal davon aus, dass es sich dabei wirklich um einen Hardware-Fehler im virtuellen Speichersystem handelt, vielleicht auch in der Virtualisierung VT-x. Dann ist es sehr wahrscheinlich, dass ein großer Teil aller laufenden Cloud-Lösungen genauso wie viele VPS davon betroffen sind. Und nicht nur das: wenn es sich wirklich um einen Rowhammer-Fehler handelt, dann sind potenziell viel mehr Systeme betroffen, weil man diese Sicherheitslücke auf mehreren Wegen ausnutzen kann, zum Beispiel sogar in einer JavaScript-Umgebung. Das betrifft in erster Linie wohl Server mit Node.js Komponenten, aber es impliziert auch, dass so ein Angriff über jeden herkömmlichen Browser möglich sein könnte. Aber das ist leichter gesagt als getan.

*) Mit Vorgehen im Fall meine ich folgendes: es handelt sich hier um Änderungen an einem Teil Code, der nicht mal schnell in ein paar Wochen komplett umgeschrieben wird wenn das nicht unbedingt nötig ist. Meist vergehen mehrere Monate wenn nicht gar Jahre, bis derart massive Änderungen vollzogen werden. Kurioserweise gibt es auch Reboots von VM Instanzen zum Beispiel bei Amazon oder Microsoft, was ebenfalls diesem Bug zugeschrieben wird. Interessant ist auch, dass jene Leute der Technischen Universität Graz nicht nur an den Änderungen des Kernels mitgearbeitet haben, sondern scheinbar unabhängig davon einen neuen Bug veröffentlicht haben (Zitat: "Our Rowhammer enclave can be used for coordinated denial-of-service attacks in the cloud and for privilege escalation on personal computers.").

Wenn die Spekulationen richtig sind, ist dies alles Teil einer hastig choreographierten Panikreaktion, um die Sicherheit der Systeme gewährleisten zu können bevor Informationen über die Schwachstelle öffentlich werden.

Abschließend den Geschwindigkeitseinbruch betreffend: es geht hier darum, dass die Performance von system calls leidet weil der CPU Cache der Adressen speichert mit jedem neuen call geleert werden muss. Wenn man also unter Linux einen Benchmark nutzt der fast ausschließlich das tut, dann werden die Einbußen natürlich ziemlich groß sein. Mich überraschen da auch 50-60% keineswegs, schließlich setzt man damit Methoden (und Tricks) außer Kraft die CPUs auf Kosten der Sicherheit beschleunigen. In der Praxis dürfte das Problem wesentlich geringer sein, aber selbst 5% oder 10% können unter bestimmten Umständen zum großen Problem werden.

@SavageSkull: Im TLB (das was du "Pufferspeicher" nennst) stehen nicht die Daten selbst, sondern ein Mapping der logischen Adressen (mit denen Prozesse arbeiten) auf die physischen Adressen deines RAM. Die Sicherheitslücke ist nicht, dass Proezss A auf den Speicher von Prozess B zugreifen kann, sondern dass ein einfacher Prozess auf den Speicher des Betriebssystem-Kerns zugreifen kann, der ihn gar nichts angeht (selbst wenn es nur lesend ist).

Vielleicht mit diesen Infos die News nochmal lesen.

@dreamy_betty: Sehr schön geschrieben!

Warum haben AMD CPUs diesen Bug nicht?
Gibt es dafür Infos?

Die haben es anders implementiert.

SavageSkull schrieb:

Kann man das auch mal für nicht IT Menschen erklären?
Das habe ich jetzt verstanden:
Die CPUs haben einen Pufferspeicher (Cache), auf den laufende Programme zugreifen.
Es ist möglich, dass Programme auf Dateien im Cache Zugriff haben, die zu einem anderem Programm gehören?
Die Software Lösung sieht vor, den Pufferspeicher ständig zu löschen, was unter Umständen Leistung kostet.

Zum Vergrößern anklicken....

https://de.wikipedia.org/wiki/Virtuelle_Speicherverwaltung
https://de.wikipedia.org/wiki/Translation_Lookaside_Buffer

Eins vorweg, ich versuche es nur so zu erklären, wie ich es verstanden habe. Wenn es jemand besser weiß, kann er/sie mich gern auch verbessern.

Also, der TLB ist quasi für die Übersetzung von virtuellen zu physischen Adressen da. Jede virtuelle Adressse wird auf eine physische Adresse abgebildet, über die dann der eigentlich Zugriff erfolgt. Jeder Prozess hat seinen eigenen virtuellen Adressraum um die Kapselung zu gewähleisten (die hier aus dem Sicherheitsaspekt wichtig ist). Wird der Prozess gewechselt, wird der TLB gelehrt und mit den entsprechenden Daten für den neuen Prozess geladen.
Wenn man es geschickt anstellt und durch Prefetchen eine nicht zu dem Prozess gehörende Adresse im TLB steht, kann man auf den Speicher des fremden Prozesses zugreifen. Das kann ein Betriebssystem-Prozess sein, mit dem man dann Code im Kernel-Mode ausführen kann. Kernel-Mode = "Ich darf mit diesem Rechner alles (wirklich alles)". An der Stelle hat man dann verloren und man muss es nicht einmal merken.

Die Lösung ist jetzt den TLB soweit es geht zu umgehen, was dazu führt, dass die Adressen bei jedem Laden eines Prozesses neu aufgelöst werden müssen. Das ganze bremst entsprechend aus.

Wie gesagt, garantiere ich keine Richtigkeit, aber in Grundzügen dürfte das das Problem sein. TLBs sind wesentlich komplizierter als hier dargestellt.
Wenn man nur ein Spiel hat und wenige Prozesse laufen, wird das nicht weiter auffallen. Wenn am System aber mehr gemacht wird, entstehen die 67% und die Leistung geht flöten.

Das ganze ist Hardwarelogik und kann nicht einfach durch Intel geändert werden. Dafür bräuchte es Veränderungen an der Architektur.

AMD unterbindet einfach, dass Daten von Prozessen mit höhren Rechten im TLB landen. Daher kann der Fehler nicht auf AMD-Prozessoren in dieser konkreten Form auftreten, was AMD auch (wohl bewusst...) so formuliert.

Maxminator schrieb:

Gibt es dafür Infos?

Zum Vergrößern anklicken....

Ja, unter anderem mehrmals in diesem Thread...

Na ja, El Reg.
Kann was dran sein, und dann wieder auch nicht.

Der Großteil der britischen Presse ist mit Vorsicht zu genießen.
The Guardian und ganze wenige andere sind da wohl eine Ausnahme,
"The Register" jedoch definitiv nicht.

Intel sollte Stellung nehmen.
Vorher ist und bleibt alles - wie in der Headline angemerkt - Spekulation.

-

Ich will ja mal nichts meinen, aber wie sieht es denn bei vmware aus? Müsste dort solch eine Sicherheitslücke nicht potentiell viel tragischer sein als unter Windows? Bedient sich vmware hier dem Linux Patch, oder stellen die was eigenes auf die Beine? Ich mein, so etwas dürfte ja Performance zu nichte machen wie blöd.

Huhu,

öhm doch besser ein AMD kaufen ^^

Puhhhh was kaufe ich nun !!! Grübel

Beyazid schrieb:

Die News der letzten Monate bzw. im ganzen Jahr 2017 über Intel sind ziemlich negativ gewesen und bestärken mich in der Entscheidung beim nächsten Prozessor AMD zu kaufen.

Zum Vergrößern anklicken....

Vorausgesetzt es waren nicht Leute von AMD, die gezielt gesucht haben, um Intel eins reinzudrücken. "Also bei uns gibts ja sowas nicht^^" (zutrauen würde ich es AMD)

Aber Intel verfolg tatsächlich eine schlechte Nachricht nach der anderen, ist schon komisch.

Erst vor einigen Monaten wurde die Sicherheitslücke in der TXE Engine bekannt gegeben. 6 Monate alte ApolloLake NUC betroffen und aktuell immer noch nicht patchbar."Die erkannte Version der Intel(R) Trusted Execution Engine Firmware wird für INTEL-SA-00086 als anfällig angesehen. Wenden Sie sich an Ihren Systemhersteller, um Unterstützung und Abhilfe für dieses System zu erhalten.
Weitere Informationen finden Sie in der SA-00086 Detection Tool Anleitung oder in der Intel Sicherheitswarnung Intel-SA-00086 auf der folgenden Webseite: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr" Bis heute auf der download Seite keine freigegebene sichere Version vorhanden. Low budget Kundschaft Intel ist egal.
Für mich kein Weltuntergang, das ganze System ist nur 200 euro wert. Etwas confuser wird im High End Segment, wenn Intel mit OS Hersteller genauso konsolidiert und akribisch die aktuelle Lücke bearbeitet

@ CS74ES
Selbst wenn dem so gewesen wäre, was würde das an dem Problem ändern?
Wären die dann die Bösen weil sie eine schwere Sicherheitslücke entdeckt und die heile wohlfühl Welt kaputt gemacht hätten?

CS74ES schrieb:

Vorausgesetzt es waren nicht Leute von AMD, die gezielt gesucht haben, um Intel eins reinzudrücken. "Also bei uns gibts ja sowas nicht^^" (zutrauen würde ich es AMD)

Zum Vergrößern anklicken....

Selbst wenn es so wäre, wäre die Lücke trotzdem vorhanden und man hätte sie früher oder später gefunden, und ausgenutzt. Unter Umständen wird oder wurde diese Lücke schon ausgenutzt.

Volkimann schrieb:

Selbst wenn es so wäre, wäre die Lücke trotzdem vorhanden und man hätte sie früher oder später gefunden, und ausgenutzt. Unter Umständen wird oder wurde diese Lücke schon ausgenutzt.

Zum Vergrößern anklicken....

Existiert sicher schon seit ein paar Jahren im Arsenal der NSA und wie die auf ihre Exploits auspassen, wissen wir seit WannaCry ja.

CS74ES schrieb:

Vorausgesetzt es waren nicht Leute von AMD, die gezielt gesucht haben, um Intel eins reinzudrücken. "Also bei uns gibts ja sowas nicht^^" (zutrauen würde ich es AMD)

Zum Vergrößern anklicken....

Ist ne Verschwörungstheorie, wenn ich überlege was AMD die letzten Jahre durchmachen musste könnte man auch Intel einen schwarzen Peter zuschieben, da arbeiten nämlich auch keine Engel. Bringt also niemanden weiter.

Aber es würde so oder so keine Rolle spielen, weil der Bug ja nicht untergeschoben wurde. Wenn die aktuellen Hinweise sich bewahrheiten dann war der Bug die ganze Zeit da und damit liegt die Schuld bei dem der ihn verursacht hat und nicht bei dem der ihn gefunden und veröffentlicht hat. Wer ihn ausgräbt und warum spielt keine Rolle, Bugs müssen gefixt werden und nicht geheimgehalten. Geheimhaltung ist nur sinnvoll um eine Fehlerbehebung zu ermöglichen. Daher wird aktuell wohlt auch so viel spekuliert, weil die NDA Phase scheinbar noch läuft. Aber anschließend müssen alle Fakten schleunigst auf den Tisch, damit die Verbraucher sich schützen können. Ich werde bei mir keine Sicherheitslücke durchschleppen nur um Performance zu retten.