Diskussion zu: Sicherheitslücken "Meltdown" & "Spectre" in Intel-, AMD- und ...

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/sicherheitsluecken-meltdown-spectre-intel-amd-und-arm-prozessoren-benannt

[Gast]

Link zur News:
https://www.3dcenter.org/news/sicherheitsluecken-meltdown-spectre-intel-amd-und-arm-prozessoren-benannt

Das ist keine mittelschwere Katastrophe, das hat Potential für einen Supergau der ganzen IT-Branche.

[Leonidas]

Dazu müsste man mehr wissen, wie real ausnutzbar Spectre nun ist. Meltdown dürfte dagegen nächste Woche erledigt sein.

[FlashBFE]

Danke für die gute Zusammenfassung des Themas. Das haben nicht alle Nachrichtenseiten so klar hinbekommen. Golems Artikel ist beispielsweise besonders schlecht, weil noch voller Spekulation und ohne Fakten, aber bis jetzt eben auch ohne Aktualisierung.

– dafür allerdings (glücklicherweise) mit Betriebssystem-Updates schnellstmöglich aus der Welt zu schaffen sein wird. AMD wehrt sich ja bei Linux gegen den Meltdown-Patch, weil das Performance kosten kann, ohne dass sich AMD davon betroffen sieht. Es wäre schon, wenn du da dran bleibst bei der Frage, ob die Meltdown-Patches für alle Architekturen wirken oder nur für die tatsächlich betroffenen. Denn es gab ja schon einige Jubelschreie, die darin einen Performance-Vorteil für AMD sahen, der nun vielleicht doch nicht wirksam wird.

[Ganon]

Der Patch von AMD wurde in den Linux Kernel aufgenommen und wird im nächsten Release enthalten sein.

[Fusion_Power]

"Meltdown betrifft alle Intel-CPUs seit dem Jahr 1995..."

Und das ist erst jetzt aufgefallen? Niemals vorher, trotz so vieler Tests die hoffentlich bei der CPU Entwicklung gemacht werden? Und suggereirt das, dass die Hersteller Teile ihrer Prozessoren seit 1995 einfach so 1:1 übernommen haben? Kann ja eigentlich nicht sein oder? So oder so, großer Skandal, da kommt sicher noch was auf uns zu, GZ schon mal an alle Serverbetreiber.

[Ganon]

CPUs werden nicht all Nase lang neu erfunden. Genauso wie du in Windows 10 noch Code aus Windows 95 Zeiten finden wirst, wirst du in CPUs auch Zeug aus den 90ern finden.

[Fusion_Power]

CPUs werden nicht all Nase lang neu erfunden. Genauso wie du in Windows 10 noch Code aus Windows 95 Zeiten finden wirst, wirst du in CPUs auch Zeug aus den 90ern finden.
Echt? Das letzte was ich in Win10 finden will ist noch code von 1995, man kann eigentlich erwarten auch mal alte Zöpfe abzuschneiden, wozu propagieren die Hersteller immer ihre "völlig neu entwickelte" Hard/Software? Ich fands ja schon kurios, in Win 10 die gute alte "moricons.dll" zu finden, die gabs schon in Windows 3.1 für weitere Icons. :freak:

[Ganon]

Versuche mal im Explorer einen Ordner Names "AUX" oder "COM1" anzulegen. Das sind noch Relikte aus Windows 9x und DOS Zeiten und immer noch drin. Wer weiß wo überall noch.

[Gast]

Hier gibt es die offizielle Aussagen von AMD:
https://www.amd.com/en/corporate/speculative-execution

[Gast]

Meltdown und Spectre

AMD Prozessoren sind nur in einem wissentschaftlich provozierten Angriffsfall auffällig, One Bounds Check Bypass. Branch Target Injection und Rogua Data Cache Load zeigen keine Auffälligkeiten auf AMD Prozessoren, wobei Intel jeweils durch alle 3 Angriffsvarianten betroffen ist. AMD ist dabei durch Architekturunterschiede zu Intel CPUs geschützt. Wie bekannt kann ihnen alles andere nichts anhaben.

M$ hat bereits einen Patch für Windows 10 dazu veröffentlicht und Apple hat schon vorher reagiert, das Securityupdate sollte erst am 09.01.2017 online gestellt werden. Ich konnte ihn schon heute morgen (um 00:irgendwas) updaten.

Einfach mal manuell nach Updates suchen, ist erstmal die erste (sicherste) Wahl und dann neu starten. Leistungsunterschiede merke ich nicht. Intel wird sicher noch ein 'offizielleres' Statement abgeben, daß erst Mitte Januar 2018 geplant war.

Bitte diesen Hinweis beachten: https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released da es Probleme mit Antivirenprogrammen geben kann.

[Birdman]

Der Patch von AMD wurde in den Linux Kernel aufgenommen und wird im nächsten Release enthalten sein.
Gibt es bereits irgendwelche Infos wie dies bei Windows und OSX gehandhabt wird?
Wurde hier KPTI quasi auch mit der Keule für alle Architekturen aktiviert oder nur für spezifische CPU Modelle/Vendors?
Bei Macs ists ja weniger tragisch, da es (zumindest offiziell) eh nur Intel gibt, aber Windows/AMD User wären sicher weniger glücklich, wenn sie den Performance-Malus mittragen müssen, obwohl dies gemäss aktuellen Erkentnissen nicht notwendig wäre.

[Ganon]

Da der ganze Kram ja nun wohl etwas eilig vorgezogen wurde, fehlen halt noch die ganzen offiziellen Statements. Die trudeln jetzt erst nach und nach ein. Muss man halt gucken ob MS irgendwas sagt, ansonsten halt Benchmarks fahren.

[Gast]

Danke für die gute Zusammenfassung des Themas. Das haben nicht alle Nachrichtenseiten so klar hinbekommen. Golems Artikel ist beispielsweise besonders schlecht, weil noch voller Spekulation und ohne Fakten, aber bis jetzt eben auch ohne Aktualisierung.


Dann wäre aber schön, wenn die sogenannten Fakten auch stimmen würden.

Beispiel:
In beiden Fällen geht es grob um das Auslesen von Daten fremder CPU-Prozesse, wobei man mittels Meltdown sogar an Systemdaten herankommt und mit Spectre "nur" an die Daten anderer Anwendungen.

Meltdown kommt an den kompletten Kerneladdressraum ran, was vor den Patches unter Linux an den Inhalt des kompletten physischen Arbeitsspeichers kommt. Windows bildet nicht immer den vollständigen physischen Speicher im Kerneladressraum ab, aber in der Praxis ist auch hier ein Großteil des physischen Speichers verfügbar.

Damit kommt man mit Meltdown selbstverständlich potentiell an alle Daten von allen aktuell laufenden Prozessen.

Warum hier auch das "nur" eingefügt wurde weiß ich auch nicht, irgendwie impliziert es, dass es weniger schlimm ist an die Daten anderer Anwendungen zu kommen. Dabei werden sich gerade hier potentiell sicherheitsrelevante Daten wie beispielsweise Passwörter befinden.

Ein Unterschied ist, dass man mit Meltdown prinzipiell an die Daten aller laufenden Anwendungen kommt, mit Spectre grundsätzlich "nur" an die Daten der explizit attackierten Anwendung (wobei man natürlich auch mehrere Anwendungen auf dem Zielsystem attackieren könnte).

Dies ist insbesondere in Server-Umgebungen und dort beim Einsatz von Virtualisierung tödlich, da virtuelle Maschinen je gerade dafür angelegt werden, damit jene nicht an die Daten des Host-Systems oder anderer VMs herankommen.

Wenn man das Paper zu Meltdown gelesen hätte, würde man wissen, dass Meltdown immer nur mit einem Prozess arbeitet und auch nur auf Daten zugreifen kann die in den Adressraum des Prozesses eingebunden sind.
Da im Adressraum des Prozesses logischerweise nur der Kernel eingebunden auf welchem der Prozess läuft, können logischerweise auch nur Daten geleakt werden die sich in diesem Kernel befinden.
Bei einer echten Virtualisierung läuft aber für jede Virtuelle Maschine ein eigenes Betriebssystem, sprich auch ein eigener Kernel. Daten aus anderen auf dem selben Host laufenden Betriebssystemen können damit nicht geleakt werden.
Lediglich bei Paravirtualisierung (z.B. Xen PV), in welcher alle Gäste auf dem selben Kernel laufen, ist ein Leak der Daten aus anderen Gästen möglich.

Dafür ist Spectre allerdings auch erheblich schwieriger auszunutzen, da neben dem eigentlichen Spectre-Angriff auch noch eine (nicht triviale) Seitenkanalattacke notwendig wird, um den angezapften Speicher auch wirklich auszulesen.

Beide Attacken sind nicht triviale Seitenkanalattacken.
Was Meltdown allerdings um einiges einfacher macht ist erstmal, dass es sich um eine einzige Attacke handelt, während Spectre verschiedenste Attacken ausformuliert.
Gleichzeitig muss man mit Meltdown "nur" einen User dazu bringen seinen speziell präparierten Code auszuführen, Kenntnisse über das verwendete System sind kaum notwendig.
Spectre ist dagegen darauf angewiesen eine bestimmte Anwendung zu attackieren, was Kenntnisse der Arbeitsweise der entsprechenden Anwendung voraussetzt und natürlich auch die Möglichkeit die den Programmverlauf dieser Anwendung von außen überhaupt zu steuern. Zusätzlich sind genaue Kenntnisse der verwendeten CPU-Architektur notwendig, um die Caches und Branch-Prediction-Units entsprechend zu präparieren, damit ein erfolgreicher Angriff überhaupt möglich ist.

Bei Spectre (welches sich technisch noch in zwei Einzel-Varianten zerteilt) sind hingegen derzeit alle Prozessoren betroffen, selbst wenn ARM dies bislang noch verneint und AMD verklausiert davon spricht, nicht von allen Lücken gleichzeitig betroffen zu sein.

ARM spricht davon, dass die Cortex-M-Reihe nicht betroffen ist, was naja irgendwie naheliegend ist, wenn ein Angriff die Eigenheiten der out-of-order-execution ausnützt, dass CPUs die gar kein OOE beherrschen nicht davon betroffen sind.

Intel hat sich im übrigen genauso awardverdächtig versucht aus der Affäre zu ziehen, indem man erklärte, das Berichte, wonach allein Intel-Prozessoren betroffen seien, natürlich falsch seien.
Warum jetzt auf Intel hingehauen wird ist mir nicht ganz klar, Intel ist bis jetzt der einzige der Prozessorhersteller der zumindest halbwegs detailliert zu den Problemen Stellung genommen hat und auch Lösungsvorschläge bringt.

[Gast]

Und das ist erst jetzt aufgefallen? Niemals vorher, trotz so vieler Tests die hoffentlich bei der CPU Entwicklung gemacht werden?

Weil es auch nicht wirklich ein Fehler ist. Der Zustand der (sichtbaren) Register in der CPU ist stets korrekt. Auch die Exception aufgrund des unerlaubten Speicherzugriffs wird korrekt behandelt.

Eine moderne CPU arbeitet mit in-order-issue, out-of-order-execution und in-order-writeback.
Die CPU muss garantieren, dass das Ergebnis trotz out of order execution das selbe ist, wie wenn der Code in order ausgeführt würde. Das passiert auch.

Dass jemand aus dem "magischen" dazwischen der out-of-order-execution, was von außen nirgends sichtbar ist irgendwelche sinnvollen Informationen erhalten kann hat eben niemand bedacht.
Und wie man sieht hat es auch über 20 Jahre gedauert bis einige verdammt klugen Köpfe zu diesem alles anderen als trivialen Angriff gekommen ist.

Es ist auch alles andere als trivial diese Probleme in Hardware zu lösen, da es nunmal daran liegt wie out-of-order-execution funktioniert.



Und suggereirt das, dass die Hersteller Teile ihrer Prozessoren seit 1995 einfach so 1:1 übernommen haben? Kann ja eigentlich nicht sein oder?

Ich verrate dir jetzt mal ein Geheimnis.
Die meisten heute gebauten Autos verwenden 4 Räder, ein Lenkrad und 3 Pedale. Und sie werden von einem Verbrennungsmotor, der ua. aus Kolben, Ventilen, Nockenwellen und Kurbelwelle besteht angetrieben. Das komisch, das war auch schon vor 20 Jahren so.

Natürlich sind die Grundbausteine der Prozessoren die selben wie 1995. Ein Adder sieht heute nicht anders aus als damals (außer natürlich dass er viel kleiner ist).
Der Grundlegende Algorithmus für OOE, welcher die Grundlage aller modernen Prozessoren ist, wurde auch schon in den 60er oder 70er Jahren des letzten Jahrtausend entwickelt.

Echt? Das letzte was ich in Win10 finden will ist noch code von 1995, man kann eigentlich erwarten auch mal alte Zöpfe abzuschneiden, wozu propagieren die Hersteller immer ihre "völlig neu entwickelte" Hard/Software?

Als Softwareentwickler kann ich dir sagen, dass das so üblich ist.
Ich selbst arbeite an einer Software deren Entwicklung vor 30 Jahren gestartet wurde, und der älteste Code der noch verwendet wird dürfte irgendwo im Bereich 20-25 Jahre alt sein.

In dem Code stecken mehrere Menschenleben an Zeit, das wirft man nicht einfach so weg. Der Kunde will schließlich nicht auf Funktionalität verzichten und erwartet gleichzeitig noch, dass an echten Neuerungen gearbeitet wird und nicht nur alte Funktionalität modern neuimplementiert wird.

[Gast]

Meltdown und Spectre

AMD Prozessoren sind nur in einem wissentschaftlich provozierten Angriffsfall auffällig, One Bounds Check Bypass. Branch Target Injection und Rogua Data Cache Load zeigen keine Auffälligkeiten auf AMD Prozessoren, wobei Intel jeweils durch alle 3 Angriffsvarianten betroffen ist. AMD ist dabei durch Architekturunterschiede zu Intel CPUs geschützt. Wie bekannt kann ihnen alles andere nichts anhaben.

In den nächsten Wochen und Monaten werden sich das noch einige Leute genauer anschauen.

Da wird bestimmt noch was kommen.

[Gast]

Das Problem ist nicht das man Sicherheistlücken stopfen kann, Intels Bug ist ein Designfehler, die Insider wissen das bereits und sie wissen das seit Weihnachten. Es sind alle Intel x86 Plattformen betroffen...konkrete Details unterliegen seint ein paar Tagen einem NDA/Embargo. Mehr will ich dazu nicht sagen...

Danke, mal wieder die guten Gastbeiträge. Wenn auch nicht alle veröffentlicht werden, naja was solls vielleicht regen sie ja mal zum Nachdenken an. Dann erfüllt auch die Arbeit die man sich macht ihren Zweck.

Und ja nochmal, es ist ein DESIGN-Fehler. Intel sagt dazu genau NIX...nVidia Taktik?

https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

Die Lösung soll jetzt vorerst sei den Speicher des Kernels komplett von Benutzerprozessen zu trennen, weil dies für getrennte Adressräume sorgt, was aber widerum dafür sorgt das der Prozessor mehr zu tun hat.

Dann dürfte man die letzten Benchmark neu schreiben und NEIN, Intel meint sie bringen in der nächsten Zeit für 90% der bis zu 5 Jahre alten x86 Hardware Patches, der Rest guckt vermutlich in die Röhre.

Prost dann mal schon, fette (Börsen) Zeiten für AMD, wahrscheinlich hat der Intel Ceo schon vorsorglich Aktien von denen gekauft...Inztel dürfte tief fallen und AMD hat damit eigentlich gar nichts zu tun. Der Riese strauchelt, oh oh.

[Eldoran]

Auch wenn der Unterschied in der Praxis nur bei einzelnen Prozenten liegen dürfte, so könnte damit die Leistungskrone von intel bei den high-fps Gamern fallen. So gesehen wird vermutlich der Release von Pinnacle Ridge und Raven Ridge noch spannender.

Neue Verschwörungstheorie: Raven Ridge ist deswegen verschoben worden

[Gast]

Auch wenn der Unterschied in der Praxis nur bei einzelnen Prozenten liegen dürfte, so könnte damit die Leistungskrone von intel bei den high-fps Gamern fallen. So gesehen wird vermutlich der Release von Pinnacle Ridge und Raven Ridge noch spannender.

Neue Verschwörungstheorie: Raven Ridge ist deswegen verschoben worden
Natürlich nicht.

Alle Prozies in Ausführungsebene Eager execution sind betroffen und Intel wusste es ganz genau, wurden auch schon im Juni 17 in Kenntnis gesetzt. Apple hatte den vermeintlichen Kaiser Patch im iOS Kernel sogar schon aktiv geschalten, ihn zwischenzeitlich aber wieder deaktivert, weil er zuviel Leistung kostet. Kriminell ist sowas.

Unter Spielen ist die CPU ausgelastet, dort braucht man die Leistung für anderes. Immer dann wie die CPU nicht ausgelastet ist, kann man untätige Ressourcen dann ala Speculative execution für Attacken nutzen.

Die TU Graz spielt bei der Entdeckung eine wesentliche Rolle (Moritz Lipp, Martin Schwarz, Daniel Gruss), weil sie an einer Art Kaiser Patch mitentwicklet haben und entdeckten das dieser im Linux-Kernel schon enthalten war. Da war man nämlich verblüfft, dass sich damit auch schon andere Wissentschaftler beschäftigt haben. Intel informierte dann irgendwann ARM und AMD. Wahrscheinlich ist man zwei- oder sogar dreigleisig gefahren und wollte Lösungen erzwingen.

Intel hatte selbst wohl kein probanten Mittel gefunden und weiss schon länger darüber Bescheid, die haben allen ins Gesicht gelogen. Der CEO verkauft dann auch noch den größten Teil seiner Intel-Aktien für 24 Mio, Dr*cks*ck und Intel senkt untypisch die Preise im Vorweihnachtsgeschäft. Das ist ein noch größerer Skandal als er bei VW gelaufen ist, ein wahres Weltuntergangsbeben für die IT Branche, kein Gerät auf Basis solcher Prozessoren ist mehr sicher (und das dürften fast alle sein). Man spricht nicht mehr von Beseitigung, sondern von größtenteils Eindämmung. Nur Hardware ohne Eager execution ist sicher gegen diese Attacken und die kann man an einer Hand abzählen.

[ottoman]

Warum jetzt auf Intel hingehauen wird ist mir nicht ganz klar, Intel ist bis jetzt der einzige der Prozessorhersteller der zumindest halbwegs detailliert zu den Problemen Stellung genommen hat und auch Lösungsvorschläge bringt.

Liegt wohl an Aussagen wie solchen hier:


https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/
In den ebenfalls veröffentlichten Frequently Asked Questions vertritt Intel weiterhin die exklusive Auffassung, dass es sich nicht um Hardware-Bugs handelt.

FAQ:
Is this a bug in Intel hardware or processor design?

No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

[Gast]

Auch wenn der Unterschied in der Praxis nur bei einzelnen Prozenten liegen dürfte, so könnte damit die Leistungskrone von intel bei den high-fps Gamern fallen. So gesehen wird vermutlich der Release von Pinnacle Ridge und Raven Ridge noch spannender.

Da die Lösung ist, den Adressbereich vom Kernel so weit es geht von der Anwendung zu trennen, kann die Performance prinzipiell nur dann verringert werden wenn die Anwendung Calls in den Kernel durchführt.
Da das bei Spielen allerdings nur sehr selten passiert, sind selbst Unterschiede größer als die Messungenauigkeit sehr unwahrscheinlich.

[AMD-Gast]

AMD geht bei beiden Varianten von einer Null Gefährdung aus (sie sagen nicht das sie nicht betroffen wären), weil die Exploits nur mit tiefergreifender Kenntnis über derzeitige CPU Architekturen, in wissenschaftlichen Umgebungen und mit weitreichenden Informationen der IHVs zu den Arcjitekturen ausgeführt werden könnten (die Daten sind nicht für jedermann und die Öffentlichkeit bestimmt); und AMD CPUs architekturabhängig nur einmal direkt betroffen sein könnten.

Man fuhr insgesamt Viergleisig (Uni Graz, German Cerberus Security, Google Project Zero + Paul Kocher der Team auch angehört, aber als einzelne Größe geführt wurde).

Wenn man jemanden Vernachlässigung vorwerfen kann, ist es Google, die größte Datenkrake am Markt. Denn die hatten Interesse daran erst Mal nur ihre eigene Infrastruktur+Plattform+Angebote sicher zu machen und scherten sich einen Dreck um andere. Wer dabei weiterspinnt, ein Samariter werden sie nie!!!

Consumersysteme werden kaum eingeschränkt werden, man kann also Entwarnung für diesen Anwendungsbereich geben und darauf hinweisen, daß übliche Nutzerverhalten auf die 'Möglichkeiten' hin anzupassen (wie immer, ist man selbst dafür verantwortlich, sitzt selbst vor dem Bildschirm und ist damit auch eine der Schwachstellen). Intel wird mit zukünftigen Patches auch die Leistung wieder steigern können.

Für die Meisten wird dieser Artikel hier reichen, um zu verstehen um was es geht. Es muß auch niemand geläutert oder geteert + gefedert werden, weil daran massiv gearbeitet wird (zwar englisch aber für den Laien gut und verständlich geschrieben):

https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/

Ob Intel vom Marketing her mit dem Thema offen umgegangen ist, mag wieder eine andere Baustelle sein. Ich würde mir wünschen, daß man sie dafür auch mal öffentlich abstraft, weil wäre es AMDs Baustelle gewesen gäbe es sicher jetzt den 'riesen' Aufstand. Wenn es Intel als Marktführer ist, wird dabei lobbyhaft alles kleingeredet. Ob es an dem Druck liegt den Intel derzeit hat, kann ich nicht sagen, eine Entschuldigung ist es trotzdem nicht.

Also nicht nur AMD begeht Fehler...den Gamer betrifft es zu 99,9% nicht, und eine 0,1%-ige Fehlerquelle ist überall stets vorhanden, nämlich man selbst und sein an den Tag gelegtes Verhalten im Umgang mit dem Medium. Der Rest ist mal wieder üble Clickbaiting-Presse. Kommt also wieder runter, denn eine einfache Ausführung ist stets ausgeschlossen und die größte Baustelle wurde bereits abgedichtet.

[Gast]

Liegt wohl an Aussagen wie solchen hier:

Eben darum verstehe ich es nicht. Intel versucht aufzuklären, während AMD nur sagt "wir sind nicht betroffen... also vielleicht doch, aber nur ein bisschen" und ARM überhaupt den Vogel abschießt und ablenken versucht indem sie erklären dass eines ihrer Produkte welches prinzipbedingt gar nicht betroffen sein kann, nicht betroffen ist.

Intel veröffentlicht immerhin eine recht brauchbare Analyse des ganzen Problems:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf

Und Intel hat Recht, es ist kein Bug weder bei Intel noch bei den anderen Herstellern. Die CPU ist während des gesamten Vorganges niemals in einem unzulässigen Zustand und auch der nicht zulässige Zugriff in den Kernelbereich wird erkannt und deshalb niemals commited.

Insbesondere die im Spectre-Paper beschriebenen Angriffe liegen inhärent an der Arbeitsweise eines Prozessors mit OOE und werden sich wohl auch nie zu 100% ausschließen lassen, außer man verzichtet gänzlich auf OOE und kehrt in die performancemäßige Steinzeit zurück.
Mit OOE lässt sich eben nicht zu 100% verhindern, dass auch Befehle ausgeführt werden die bei seriellem Programmablauf niemals ausgeführt werden dürften, und die Ausführung dieser Befehle wird immer irgendwelche Spuren hinterlassen, sei es wie hier im Cache, oder beim Stromverbrauch oder bei irgendwas anderem auf was mein begrenztes Gehirn nie im Leben kommt.

Klar wird es Hardwarelösungen geben um die in Spectre beschriebenen Angriffe zu verhindern, aber das heißt nicht, dass keine anderen Möglichkeiten gefunden werden um aus OOE doch an irgendwelche sinnvollen Informationen zu kommen auf die man eigentlich nicht zugreifen dürfte.
Und nachdem man mittlerweile auf die Idee kommt aus OOE an solche Informationen zu kommen, wird es wahrscheinlich keine weiteren 20 Jahre dauern für einen neuen Proof-of-Concept.

Die einzige Möglichkeit das komplett auszuschließen wäre auf OOE zu verzichten und in die performancemäßige Steinzeit zurückzukehren.
Oder man verabschiedet sich von x86 und gibt der Software wieder komplette Kontrolle über den Kontrollfluss in der Hardware (IA64 anyone?), was solche Attacken natürlich auch nicht zu 100% verhindert, aber die Verantwortung komplett von der Hardware weg in Richtung Software verschiebt, und damit logischerweise auch alle gefunden Schwachstellen per Software patchbar macht.

[Rabiata]

Frisch auf Heise (https://www.heise.de/newsticker/meldung/Linus-Torvalds-Will-Intel-Scheisse-fuer-immer-und-ewig-verkaufen-3934829.html)
Heftige Reaktion aus der Linux-Ecke:
Linus Torvalds: Will Intel "Scheiße für immer und ewig verkaufen"?
Link zu seiner Mail (https://lkml.org/lkml/2018/1/3/797)

Von daher wird Linux wohl NICHT ohne weiteres Patches übernehmen, in denen Intel's Meltdown-Fix auch ungeprüft auf AMD angewendet wird.
Das haben zwar schon andere hier gepostet, gestützt auf halboffizielle Ansagen von AMD, aber jetzt dürfte endgültig klargestellt sein wie gering das Vertrauen zwichen Intel und der Linux-Gemeinde geworden ist :down:.

[Gast]

Frisch auf Heise (https://www.heise.de/newsticker/meldung/Linus-Torvalds-Will-Intel-Scheisse-fuer-immer-und-ewig-verkaufen-3934829.html)
Heftige Reaktion aus der Linux-Ecke:
Linus Torvalds: Will Intel "Scheiße für immer und ewig verkaufen"?
Link zu seiner Mail (https://lkml.org/lkml/2018/1/3/797)

Von daher wird Linux wohl NICHT ohne weiteres Patches übernehmen, in denen Intel's Meltdown-Fix auch ungeprüft auf AMD angewendet wird.
Das haben zwar schon andere hier gepostet, gestützt auf halboffizielle Ansagen von AMD, aber jetzt dürfte endgültig klargestellt sein wie gering das Vertrauen zwichen Intel und der Linux-Gemeinde geworden ist :down:.
Das ist typisch Linus, aber was anderes kann man nicht machen wenn Intel nur Marketingpflickschusterei betreibt.

Jetzt bekommt das Gebashe gegen die billigen Ryzen/Epyc/Threadripper von seiten Intels eine neue Dimmension, das Geprügel der 8-Gen in den Markt auf Teufel komm raus. AMD hat zwar auch Spectre am Hintern, aber weit weniger als Intel und schließt Angriffe ja fast zu aus, bzw. deklariert sie über die eine Lücke ohne weitere Informationen zur Architektur als fast unmöglich. Ich kann mir ehrlich gesagt nicht vorstellen, so wie Linus schreibt das da einer drüber schauen muss, die wissen das ganz genau und tun so als würden sie keinerlei Probleme haben. Größenwahn halt bei Intel. Bashen aber intensiv gegen AMD, weil die eben meinen, tut mir leid Intel aber ich habe deine Probleme nicht, meine eine Lücke werde ich schon in Griff bekommen.

Genau das juckt Intel doch, die brauchen einen völlig neue Architektur und AMD kann zwischenzeitlich mit gefixten Zen Kohle machen...Good Job Jim Keller.:up:

Das wissen alle und nur darum geht es Intel. Traurig...Priorität müssten jetzt alle Kunden haben und nicht so ein Bullshit. Dann braucht man sich nicht wundern das man bald Klagen am Ar*ch hat. Für AMD ist das die Stunde null, einfach zu geil wie Sterne vom Himmel fallen können.:biggrin:

Jahrelang nichts gemacht als Preise dominiert und bis jetzt nur Scheiße verkauft. Linus hat Recht. Sie haben es verdient, wer den Markt so billig monopolisiert ist selbst an seinem Dilemma Schuld. Ich habe kein Mitleid.:P

Wahrscheinlich kaufen sie mit Ihrer Kohle jetzt alles wieder schön.:down:

[Eldoran]

Natürlich nicht.

Alle Prozies in Ausführungsebene Eager execution sind betroffen und Intel wusste es ganz genau, wurden auch schon im Juni 17 in Kenntnis gesetzt. Apple hatte den vermeintlichen Kaiser Patch im iOS Kernel sogar schon aktiv geschalten, ihn zwischenzeitlich aber wieder deaktivert, weil er zuviel Leistung kostet. Kriminell ist sowas.

Unter Spielen ist die CPU ausgelastet, dort braucht man die Leistung für anderes. Immer dann wie die CPU nicht ausgelastet ist, kann man untätige Ressourcen dann ala Speculative execution für Attacken nutzen.

Die TU Graz spielt bei der Entdeckung eine wesentliche Rolle (Moritz Lipp, Martin Schwarz, Daniel Gruss), weil sie an einer Art Kaiser Patch mitentwicklet haben und entdeckten das dieser im Linux-Kernel schon enthalten war. Da war man nämlich verblüfft, dass sich damit auch schon andere Wissentschaftler beschäftigt haben. Intel informierte dann irgendwann ARM und AMD. Wahrscheinlich ist man zwei- oder sogar dreigleisig gefahren und wollte Lösungen erzwingen.

Intel hatte selbst wohl kein probanten Mittel gefunden und weiss schon länger darüber Bescheid, die haben allen ins Gesicht gelogen. Der CEO verkauft dann auch noch den größten Teil seiner Intel-Aktien für 24 Mio, Dr*cks*ck und Intel senkt untypisch die Preise im Vorweihnachtsgeschäft. Das ist ein noch größerer Skandal als er bei VW gelaufen ist, ein wahres Weltuntergangsbeben für die IT Branche, kein Gerät auf Basis solcher Prozessoren ist mehr sicher (und das dürften fast alle sein). Man spricht nicht mehr von Beseitigung, sondern von größtenteils Eindämmung. Nur Hardware ohne Eager execution ist sicher gegen diese Attacken und die kann man an einer Hand abzählen.
Das ist nicht das was ich meinte - die bisherigen Spiele Tests mit dem Patch sehen eigentlich nur bei den CPU-begrenzten Szenarien Unterschiede, was soweit auch logisch ist. Das sind eben gerade die HD Benchmarks auf denen hier im Forum einiger bei Ryzen herumgeritten sind... Wenn ohnehin alles an der GPU hängt, wie unter UHD zeigen sich da keine klaren Unterschiede.
Es ist schon klar, wenn viele Frames gerechnet werden, kommen eben die dafür anfallenden Context switches häufiger an und das ganze wird nicht mher so sehr von der GPU gebremst, man sieht also Verzögerungen im kritischen Pfad der CPU eher. Weiters ist es ganz allgemein bei out-of-order-execution so, dass branch prediction relevant ist, vor allem durch das pipelining. Da ist es auch ziemlich egal, ob die CPU ausgelastet ist, oder nicht. Schon allein durch die Tiefe der Pipeline hat man bei branches mehrere Taktzyklen, in denen theoretisch nichts gemacht werden könnte und in denen macht man dann Speculative execution.
Aber das wichtigste aus Performancesicht ist dabei eben bei möglichst vielen Fällen nicht nur richtig den Sprung vorauszusagen, sondern eben auch möglichst immer dem beim Sprung "richtigen" daraus folgenden Code auszuführen, also pipeline stalls zu vermeiden. Offenbar war da intel eben zu sorglos, bzw. davon überzeugt im Fehlerfall eben alle Änderungen korrekt zurücksetzen zu können. Das ist aber offenbar nicht der Fall.

Ob in diesem Szenario - ich spiele gerade "X" ein Angriff läuft ist eigentlich völlig irrelevant, mit dem Patch kommt es eben zu mehr oder weniger messbaren Verzögerungen. Und "Angriff" ist immer relativ - kann ja auch nur automatisch laufende Malware sein.