News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)

[Complicated]

Genau diese Diskussion ist das Ziel der Intel-Desinformationskampagne gewesen. Warum sonst sollten 2 völlig unterschiedliche Exploits den selben Namen bekommen mit Versionsnummern. Meltdown war schnell zu fixen, doch Spectre v1 ist übergreifend. Da nimmt man einfach verschiedene Sidechannel-Methoden und nummeriert sie durch, damit die Presse und Forenlandschaft nur noch über "Spectre" verkürzt diskutiert.

Verwundbar ist eine CPU wenn es einen PoC gibt. "Betroffen" ist kein Begriff aus der IT-Sicherheit, sondern ein Buzz-Word in diesem Kontext, das sich durchgesetzt hat.
Sobald man diese beiden Begriffe nämlich austauscht in dem Satz "AMD ist verwundbar/betroffen" endet auch die Diskussion und man ist sich einig und es gibt keine zwei Meinungen. Daher ist auch die Anerkennung eines Exploits mit einem PoC verbunden.
Kein PoC->Kein Exploit->Nicht verwundbar!
Betroffen? Ja, von der Berichterstattung und FUD.

 

[eratte]

Wie sich Spectre und Meltdown auf künftige CPU-Designs auswirken (heise)

 

[Iscaran]

Ich gehe jetzt nicht auf alle Sachen ein, vor allem von Seehas. Und bitte nicht steinigen - ich bin sicherlich kein Intel-FUD verbreiter.

ABER AMD wird schon wissen warum sie Retpoline einsetzen und als Mitigation AUCH für AMD Systeme aktivieren und haben wollen. Und die microcode updates machen sie sicherlich weil AMD der barmherzige Samariter ist.

Nur in aller Kürze um zu demonstrieren dass das FEHLEN von Information noch lange kein Grund zur Annahme des Gegenteils ist:

Kein PoC->Kein Exploit->Nicht verwundbar!
Betroffen? Ja, von der Berichterstattung und FUD.

Ein PoC ist ein veröffentlicher Exploit.
Nehmen wir mal an AMDs Techniker haben auf BASIS des Intel-PoC einen eigenen PoC erstellt der auf deren System lauffähig war ?

Würde man diesen dann veröffentlichen ?!? Nein ! => Kein PoC den ich verlinken kann.
Würde man evtl. eine Mitigation anbieten die gegen diese Variante des Exploits schützt ?!? JA ! => Man wird dennoch mitigations anbieten mit dem Verweis auf "Spectre 2" - obwohl man damit gegen was abgewandeltes schützt.

Genau das hat AMD getan....sonst hätte man auch direkt Retpoline vs Spectre V2 ABGELEHNT als nötige Mitigation....

Also - Ruhig Blut. Intel kriegt mit Foreshadow noch genug Performance-Bremse (5-15% im "Best case") auf Server-Ebene (Desktop eigentlich auch, aber da werden die meisten behaupten man müsse das ja nicht aktivieren).

Das ist IMHO der Grund wieso aktuell AMDs EPYC auch einschlagen wie Bombe - nicht nur weil die Leistung an sich gut ist und der Preis eh top ist....sonder weil man auch diese gangen Probleme wir Foreshadow und Meltdown eben NICHT hat !

EDIT: Fakt ist die bisherigen PoCs funktionieren auf AMD nicht. GGf. mit weiteren Anpassungen aber schon - einzig und allein deshalb hat AMD auch Retpoline und andere Schritte unternommen.
Sorry ich bin kein CPU-Arch experte, aber dieser simple logische Schluss ist mir mehr als Einleuchtend - AMDs eigene Leute werden schon wissen warum man dennoch Mitigations gegen bestimmte Sachen abietet.

 

[Complicated]

Würde man diesen dann veröffentlichen ?!? Nein ! => Kein PoC den ich verlinken kann.

Ich verstehe was du damit ausdrücken willst. Doch hier sehe ich auch eben den Beleg für deine Logiklücke.
Wird eine Lücke vom Hersteller geschlossen bevor sie publik wird ist es kein Exploit mehr. Ein PoC muss eine nicht geschlossen Lücke darstellen zu dem Zeitpunkt der Veröffentlichung. Das ist eben wie ein PoC definiert wird. Wenn AMD die Lücke selber findet und schließt, sind sie ihrer Herstellerpflicht schnell genug nachgekommen um eben kein verwundbares Produkt zu haben.

Man nehme alle jemals existierenden Sicherheitslücken, welche die Hersteller von Software und Hardware geschlossen haben bevor jemand einen PoC hatte. Jeden Dienstag beim Windows Update werden solche Lücken bekannt. Niemand nennt auch nur eine der geschlossenen Lücken einen Exploit. Es wird "geschlossene Sicherheitslücke" genannt und zwar rechtzeitig bevor sie ausgenutzt werden konnte. Intel kann das nicht bieten bei Spectre v2, AMD kann das bieten bevor ein PoC möglich wurde.

Der Unterschied in der Logik ist, dass du den Auslieferungszustand nimmst und jegliche nachträgliche Patches mit einem "PoC" gleichstellst - das ist hier eben nicht zulässig wenn man korrekte Begriffe verwendet.

Edit: Übrigens wollte ich nicht den Eindruck erwecken, dass du FUD verbreitest. Sondern lediglich, dass der FUD von Intel hier bestimmte sprachliche Regelungen verschoben hat, welche zu der von dir vorgetragenen Logik führt. Ich wollte damit sagen, dass du hier diesem Detail der PR-Kampagne zum Opfer gefallen bist und daher entsprechende Sprachregelungen für richtig hältst IMHO.

 

[Iscaran]

Ich verstehe was du damit ausdrücken willst. Doch hier sehe ich auch eben den Beleg für deine Logiklücke.
Wird eine Lücke vom Hersteller geschlossen bevor sie publik wird ist es kein Exploit mehr. Ein PoC muss eine nicht geschlossen Lücke darstellen zu dem Zeitpunkt der Veröffentlichung. Das ist eben wie ein PoC definiert wird. Wenn AMD die Lücke selber findet und schließt, sind sie ihrer Herstellerpflicht schnell genug nachgekommen um eben kein verwundbares Produkt zu haben.

Ist ja in Ordnung - Aber allein auf die Wort-Semantik was wann wie "PoC" oder Exploit genannt wird würde ich mich einfach nicht berufen. Denn so 100% klar definiert wie du es beschreibst ist das nicht.

Ein Exploit kann auch existieren wenn er public ist.
Ein Exploit kann auch dann noch entwickelt werden wenn der Hersteller zwar schon Patches in Umlauf gebracht hat "vorsorglich" weil es ja genug dumme gibt die diese dann z.b. nicht aufspielen etc.
Es gibt Beispiele für solche Fälle. Wo ein Hersteller ein Bug fand, diesen "gepatched" hat, aber die Patches z.B. nicht eingespielt wurden....dann kam der "Exploit" der nach deiner Definition keiner wäre und kompromittierte die ungepatchen Systemen.

Fakt ist: Wir wissen alle hier nicht mehr bzgl. der Architektur-Details von AMD. AMD jedoch sehr wohl. Die Jungs dort werden sich den Spectre V2 PoC sehr genau angesehen haben und auch wenn der PoC so WIE er ist NICHT auf AMD funktioniert, kann ICH mir vorstellen haben die findigen Jungs dort evtl. sehr schnell gesehen dass man da nur ein "bisschen" anpassen muss und schon gibt es Varianten/Möglichkeiten auch AMD-Systeme zu attackieren.

Fakt ist AUCH: dass AMD bezüglich Spectre V2 durchaus einige Mitigations entwickelt hat.
Vermutlich aber NICHT wegen des bereits bekannten PoCs sondern wegen der Implikationen die ihre Leute sich daraus ableiten konnten und die dann wohl auch die eigenen Systeme betreffen KÖNNTEN.

Ohne tiefer gehenden Grund hätte und würde AMD nicht Zeit und Geld verschwenden um Retpoline zu entwickeln und Microcodes zu schreiben !

=> Spectre V2 "betrifft" also auch AMD "in gewisser Weise" Anders passen diese Fakten nicht zusammen. Auch wenn der existierende PoC nur eine "sehr theoretische" Möglichkeit darstellt wie AMD selbst ja auch schreibt.

 

[Complicated]

Ist ja in Ordnung - Aber allein auf die Wort-Semantik was wann wie "PoC" oder Exploit genannt wird würde ich mich einfach nicht berufen. Denn so 100% klar definiert wie du es beschreibst ist das nicht.

Oh aber es geht hier ausschließlich um Semantik. Das ist ja Intels FUD.

Ein Exploit kann auch existieren wenn er public ist.
Ein Exploit kann auch dann noch entwickelt werden wenn der Hersteller zwar schon Patches in Umlauf gebracht hat "vorsorglich" weil es ja genug dumme gibt die diese dann z.b. nicht aufspielen etc.

Ein ZERO-DAY-Exploit ist ein:

Zero-Day-Exploit nennt man einen Exploit, der eingesetzt wird, bevor es einen Patch als Gegenmaßnahme gibt. Entwickler haben dadurch keine Zeit („null Tage“ englisch zero day), die Software so zu verbessern, dass der Exploit unwirksam wird, um so deren Nutzer zu schützen.

Ist der Exploit gepatched (man nennt das dann ein "gepatchtes System"), ist der Exploit nicht mehr anwendbar und das System nicht verwundbar für diesen Angriff. Wurde zuvor niemals ein solcher Angriff durchgeführt wurde die Schwachstelle auf einem solchen System auch nicht "exploited" - Übersetzung: Ausgenutzt.
Schreibe ich also: "There is no exploit by spectre v2 on AMD based systems" ist das ebenso richtig wie wenn ich schreibe AMD Systeme sind "betroffen". Betroffen sein ist aber keine ausnutzbare Schwachstelle im Gegensatz zu den Intelsystemen zum Zeitpunkt des Bekannt werden des Exploits. Der Unterschied zwischen den Definitionen ist das Vorhanden sein eines PoCs, denn nur so hat man den Beweis für die Behauptung es gebe einen Exploit.

=> Spectre V2 "betrifft" also auch AMD "in gewisser Weise" Anders passen diese Fakten nicht zusammen. Auch wenn der existierende PoC nur eine "sehr theoretische" Möglichkeit darstellt wie AMD selbst ja auch schreibt.

Und eben das ist keine Sprachregelung der IT, sondern von Intels PR. Was bedeutet denn bitte "betroffen" "in gewisser Weise". Im Fall von AMD bedeutet das, dass sie ihre Arbeit richtig gemacht haben und die Käufer nicht gegen diese Lücke verwundbar waren als diese bekannt wurde. Und es nach wie vor nicht sind.
Intel im Gegensatz dazu kann das nicht behaupten von sich. Aber in IT-Kreisen hat sich vor "Spectre" noch nie jemand dafür interessiert ob jemand rechtzeitig einen Patch eingespielt hat bevor er bekannt wurde und das dann "vulnerable" genannt. Der Grund dafür ist, dass es belanglos ist aus technischer Sicht da gepatched.

Wichtig wurde es erst mit Meltdown und Spectre plötzlich darüber zu spekulieren ob AMD das patchen musste oder nicht, damit es keinen PoC dafür gibt. Es ist irrelevant und lenkt die Diskussion von bestehenden Problemen ab. Und zwar nur mit dem Zweck den Eindruck zu erwecken es gäbe keine Alternative die nicht auch "betroffen" wäre. Nur ist die Alternative denn von etwas relevantem betroffen, wovon Intel ebenfalls betroffen ist? Die Antwort ist Nein. Deshalb plädiere ich für die Verwendung der Sprachregelung, welche auch vor Meltdown gültig war, damit hier nicht PR-Abteilungen die Realität neu definieren. "Betroffen" war kein Teil davon und muss heute auch nicht irgendwie dort Berücksichtigung finden.

Edit: Hinzu kommt, dass Spectre V2 bis zum heutigen Tag auch auf einem ungepatchen AMD System keinen PoC hat. Nur auf einem mutwillig "scharf" geschaltetem System mit dem JIT-Compiler flag. Das ist die "Betroffenheit" von AMD. Wenn man diese Möglichkeit des aktivieren patched hat man immer noch nicht Spectre v2 patchen müssen.

 

[drSeehas]

Ich gehe jetzt nicht auf alle Sachen ein, vor allem von Seehas. ...

Na gut, dann gehe ich auf deine Sachen auch nicht mehr ein ...

Nur eines noch:
Wenn Spectre2 auf AMD funktionieren würde, dann hätte intel das schon längst rausgefunden und auch veröffentlicht.

 

[Iscaran]

"There is no exploit by spectre v2 on AMD based systems" ist das ebenso richtig wie wenn ich schreibe AMD Systeme sind "betroffen". Betroffen sein ist aber keine ausnutzbare Schwachstelle im Gegensatz zu den Intelsystemen zum Zeitpunkt des Bekannt werden des Exploits. Der Unterschied zwischen den Definitionen ist das Vorhanden sein eines PoCs, denn nur so hat man den Beweis für die Behauptung es gebe einen Exploit.

Sorry Complicated: Aber das ist doch Haarspalterei.

Auf der einen Seite sagst du es gibt keinen Exploit Spectre V2, aber gleichzeitg sagst du AMD sei dennoch betroffen.
Selbst AMD höchstselbst räumt eine grundsätzliche Anfälligkeit gegen "Spectre-artige" attacken mit ihrem Satz ein:
"While we believe it is difficult to exploit Variant 2 on AMD processors, we actively worked with our customers and partners to deploy the above described combination of operating system patches and microcode updates for AMD processors to further mitigate the risk."

IBPB is the AMD recommended setting for Windows mitigation of Google Project Zero Variant 2 (Spectre).

https://developer.amd.com/wp-conten...Guidelines_Update_Indirect_Branch_Control.pdf
Hat AMD sicherlich nicht gemacht weil gänzlich unnötig...ich denke so schlau sind die Jungs bei AMD schon dass sie so etwas nicht ohne Grund empfehlen.
AUCH WENN der eine Spectre V2 PoC auf AMD nur schwerlich geht. Vermutlich ist die Modifikation des PoC für AMD-System gar nicht "so schwer", wenn man eben die Architektur etc. kennt und ein guter Programmierer ist. Was ich NICHT BIN, aber das ist jedenfalls die Logik warum AMD hier auch Spectre V2 Mitigations umsetzt....anders kann man das in meinen Augen nicht verstehen.

So etwas würde eine Firma nicht machen wenn sie sich SICHER wären, wie im Falle von Meltdown und Foreshadow das die Lücke so auf ihrem System nicht ausnutzbar ist.

@Seehas: Sorry - ich hatte nicht die Zeit auf deinen ganzen Post im Detail einzugehen - vieles ist ja völlig richtig was du schreibst, aber ich habe das Gefühl wir reden aneinander vorbei. Nur deswegen hab ich lieber nicht jedes Detail beschrieben.
Mir geht es ja auch nur um den einen Punkt dass in meiner Kurzaufzählung kritisiert wird dass ich schrieb:
AMD sei von Spectre V2 "betroffen" sei:

Hier ist was ich aufgelistet habe:
Spectre V1 = Bounds Check Bypass (BCB) = Variant 1 = CVE-2017-5753
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753

Spectre V2 = Branch Target Injection (BTI) = Variant 2 = CVE-2017-5715
alle CPUs mit Spekulativer Ausführung
Intel, AMD, ARM,... <= und daran dass ich HIER AMD auch als betroffen nenne störst du/ihr euch offenbar
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715

Nur eines noch:
Wenn Spectre2 auf AMD funktionieren würde, dann hätte intel das schon längst rausgefunden und auch veröffentlicht.

Außerdem könnte Intel hier evtl. einfach lieber die Füße still halten als wenn sie agressiv in Richtung AMD "bashen" würde indem sie einen angepassten Spectre-PoC veröffentlichen.
Denn sonst könnte AMD ja ihrerseits ggf. Meltdown und Forshadow PoCs raushauen ?!? So eine Eskalation würde niemand etwas bringen - vor allem Intel selbst nicht.
Allein schon um eben das Risiko gering zu halten dass jemand tatsächlich Schadcode mit den PoCs kreiieren würde.

 

[Complicated]

Du sagst es sei Haarspalterei. Es ist aber der entscheidende Unterschied. Wie du hier ja selber ausführst stellst du Vermutungen ohne Proof (BEWEIS) gleich mit dokumentierten PoC.

https://developer.amd.com/wp-conten...Guidelines_Update_Indirect_Branch_Control.pdf
Hat AMD sicherlich nicht gemacht weil gänzlich unnötig...ich denke so schlau sind die Jungs bei AMD schon dass sie so etwas nicht ohne Grund empfehlen.
AUCH WENN der eine Spectre V2 PoC auf AMD nur schwerlich geht. Vermutlich ist die Modifikation des PoC für AMD-System gar nicht "so schwer", wenn man eben die Architektur etc. kennt und ein guter Programmierer ist. Was ich NICHT BIN, aber das ist jedenfalls die Logik warum AMD hier auch Spectre V2 Mitigations umsetzt....anders kann man das in meinen Augen nicht verstehen.

So etwas würde eine Firma nicht machen wenn sie sich SICHER wären, wie im Falle von Meltdown und Foreshadow das die Lücke so auf ihrem System nicht ausnutzbar ist.

Dazu sei gesagt, dass "near zero risk" genau das bedeutet was die Forscher bisher auch einzig und alleine bewiesen haben:
Wenn man das Compiler flag des ePBF JIT Compilers aktiviert, was es standardmäßig nicht ist, dann kann Spectre 2 auf AMD CPUs genutzt werden. Niemand würde so etwas Exploit nennen, da es nur absichtlich passieren kann. Das hindert jedoch AMD nicht diese Möglichkeit per Patch zu eliminieren. Sie können aber wiederum nicht mit Sicherheit wissen ob es irgendein anderes compiler flag gibt, welches hier das selbe auslösen könnte. Dies ist eine plausible Erklärung, die alles abdeckt. Die vielen "Vielleicht" und Vermutungen, welche du aufgestellt hast sind jedenfalls nicht konsistent und erklären überhaupt nichts.

 

[Iscaran]

Wie du hier ja selber ausführst stellst du Vermutungen ohne Proof (BEWEIS) gleich mit dokumentierten PoC.

Jein. Mein "betroffen" zielte eher darauf ab, ob die CPUs von den jeweiligen Herstellern ggf. Patches etc brauchen (also die Hersteller diese anbieten) als darauf, ob es bereits bekannte PoCs oder gar exploits gibt und nichts anderes. Auch zu den anderen Lücken gibt es z.T. keine echten PoCs die zugänglich sind (im Sinne von Codeschnipseln wie dem für Spectre V2) !

Da AMD selbst manche der Lücken patched - muss man davon ausgehen dass diese System zumindest von AMD selbst als potentiell gefährdet angesehen werden. Sonst hätte man das nicht gemacht !

Ja das Compiler-Flag aktivieren mit dem man Spectre V2 auf AMD zum laufen bringt legt eben bei mir den Verdacht nahe dass AMDs-Fachleute hier noch ganz andere gefahren sehen, weswegen man gegen Spectre V2 doch ein bisschen vorgeht.
(EDIT: near zero risk ist hierbei in meinen Augen gültig für den Spectre V2 PoC wie er veröffentlicht ist, aber ich denke eben INTERN hat AMD hier noch ganz andere Varianten durchgespielt und deswegen die Patcherei).

Wie gesagt - sonst würde man es doch wie im Falle Meltdown und den L1TF-Foreshadow lücken handhaben in dem man direkt sagt: "Betrifft uns aufgrund architekturieller Unterschiede nicht." (ggf. bis das Gegenteil bewiesen wird) (Bzw. man sagt eher sowas wie "Betrifft uns soweit wir wissen nicht, weil Architektur" um sich in jede Richtung abzusichern)

Dies lässt nur den Schluss zu dass im Falle von Spectre es wohl zumindest in deren EIGENEN Augen nicht so schwer ist das Gegenteil zumindest mal grundsätzlich zu beweisen. Was ja mit dem ePBF JIT flag eben im Grund schon erreicht ist.
AMD-Techniker werden sich denken können das andere "findige" Programmierer das was sie selbst herausfinden konnten dann wohl auch finden könnten - und bevor man sich dann die Häme geben muss dass ein PoC released wird NACHDEM man erst behauptet hat, "das betrifft uns nicht", hat AMD eben Mitigation für die Risiko-Wege die sie selbst sehen eben gewählt.

Auch die Admin-Access Rootlücken Stichwort Ryzenfall-Hype gehören in die Kategorie, sind allerdings nochmal eine Stufe harmloser als Spectre V2.

Kurz und gut: In meiner "Kurzliste" stehen unter betroffen nur CPUs von denen mir bekannt ist dass deren Hersteller Mitigations für bestimmte Lücken released haben oder anbieten wollen.

AMD tut dies für Spectre V2 => "betroffen" => Eintrag in meiner Liste.

Alles andere ist in meinen Augen eine Diskussion um des Kaisers-Bart.

 

[drSeehas]

... könnte ... würde ... könnte ... würde ... würde.

Also alles Spekulation.
Ich halte mich da lieber an die Fakten.

Und noch zu "betroffen":
Ja, AMD ist theoretisch von Spectre2 betroffen.
Der Grad der "Betroffenheit" zwischen intel und AMD unterscheidet sich aber sehr stark.
Intel und du versuchen, die Betroffenheit gleichzusetzen, damit intel besser aussieht als es in Wirklichkeit ist.
Und dagegen wehre ich mich. Nicht immer erfolgreich.

 

[Complicated]

Nach deiner Sichtweise gibt es keine Hardware die nicht betroffen wäre.
Das ist halt nicht die Sichtweise von Leuten die sich damit auskennen und beruflich damit arbeiten.
Auf wessen Sichtweise sollten wir uns dann hier einigen?
Ich halte mich an die der Sicherheitsforscher und IT-Fachkräfte, denn deine basiert auf deinem Bauchgefühl und ich finde das deutlich weniger überzeugend als die seit Jahrzehnten etablierten Definitionen, welche Intel aus Eigeninteresse versucht zu verschieben. Das funktioniert bei Laien ja auch wie man bei dir sieht.

 

[Iscaran]

Also alles Spekulation.
Ich halte mich da lieber an die Fakten.

JA ich auch.

Ja, AMD ist theoretisch von Spectre2 betroffen.
Der Grad der "Betroffenheit" zwischen intel und AMD unterscheidet sich aber sehr stark.

JA

Intel und du versuchen, die Betroffenheit gleichzusetzen, damit intel besser aussieht als es in Wirklichkeit ist.

Nein das mache ich nicht. Ich nehme lediglich die Fakten wahr die AMD selbst veröffentlich hat.

Das ist halt nicht die Sichtweise von Leuten die sich damit auskennen und beruflich damit arbeiten.
Auf wessen Sichtweise sollten wir uns dann hier einigen?
Ich halte mich an die der Sicherheitsforscher und IT-Fachkräfte,

Ah und die Leute die bei AMD die Microcode updates gemacht haben etc. sind keine Fachleute ?!?
AMD selbst empfielt es doch....und zwar auch bei Spectre V2 mittels Retpoline und anderer Varianten (IBPB bei Windows) dagegen vorzugehen.

Das machen die nicht aus "Spaß" oder weil sie keine Fachleute sind.

Jetzt kommt doch noch eine Vermutung dazu meinerseits: Vermutlich weil sie weit MEHR über Spectre (v2) verstehen als wir alle hier zusammen machen sie das genau so wie sie es machen.

 

[tomturbo]

Der Microcode-Update von AMD kommt ziemlich wahrscheinlich aus dem Zwang mit Windows und dessen "Vermeidungsmaßnahmen" kompatibel bleiben zu können.
Das hat nichts mit dem zu tun was bei Intel gemacht werden muss.
Nachdem es keinen POC gibt gibt es auch keinen Fehler zu patchen, denn AMD wäre verpflichtet so einen fatalen Fehler zu veröffentlichen und nicht zu verheimlichen, wenn gerade die Konkurrenz deswegen stark um Rampenlicht steht und alles unternimmt um auf andere zeigen zu können.

 

[Complicated]

@Iscaran
Du reimst dir Dinge zusammen ohne die nötige Fachkenntnis, wie du es ja selber zugibst.
Ich finde das äußerst ermüdend, da es mit dem Thema eigentlich nur peripher zu tun hat. Dies hier ist auch nicht ein Spekulationsthread. Und auch wenn das Thema zum spekulieren einlädt, so sollte man bei den Fakten bleiben. Das Gegenteil davon nennt sich nämlich FUD: Fear, Doubt and Uncertainty - Intels PR-Strategie, die bei eben weniger tief im Thema steckenden Personen genau diese Argumentation auslöst wie bei dir. Zielgruppe sind Presse und Börsenanalysten. Deren Sprachregelung hat sich ebenso in dieses Wischi-Waschi verwandelt wie deine Argumentation ist.

Wir sind hier in einem technischen Forum, also lass uns mal in diesem Kontext festhalten, dass "betroffen" kein technischer Zustand von Hardware ist.
Verwundbar oder nicht ist das einzige, was hier relevant ist. AMD ist nicht verwundbar für Spectre V2, denn dafür gibt es keinen Nachweis. AMD hat Patches ausgeliefert um auch die böswillige Abschaltung von Compiler flags als Zugang zu Spectre V2 zu verhindern. Du denkst es ist anders? Beweise es wie es sich in einem Technik-Forum gehört oder nimm die fachliche Meinung anderer Foristen an, die du mit Spekulationen in keiner Weise widerlegen kannst.

 

[drSeehas]

... Ich nehme lediglich die Fakten wahr die AMD selbst veröffentlich hat. ...

Nein, das tust du leider nicht vollständig. Ich habe AMD-Links gepostet und daraus zitiert.

Wenn du dich nur ein bischen mit Spectre2 und AMD beschäftigt hättest, dann wüsstest du, warum AMD "near zero risk" schreibt und warum es nach über einem Jahr immer noch kein Proof of Concept gibt (und, Achtung: Spekulation, wahrscheinlich auch nie geben wird).

 

[eratte]

L1 Terminal Fault: Intel untersagt Herstellern eigene CPU-Benchmarks (Computerbase)

 

[Iscaran]

https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html

Wow wenn man sich mal hier schön die Auswahl an Benchmarkfällen ansieht und das kleingedruckte liest. Intel präsentiert ja erstmal schön all die einfachen Fälle wo im Non-Virtualized non-Hyperthreading Desktop segment gemessen wird. Wo wenn ich das richtig verstanden habe quasi der originale Meltdown Patch ausreicht. Und stellt fest dass sie in diesen Fällen keine Leistung verlieren.

ABER: Im Server-Bereich, mit HT und mit Virtualisierung, also genau da wo Epyc angreift verliert Intel deutlich Leistung, z.T. über 30% !

Und dazu dann noch den Benchmark-Knebel...das Ergebnis wird also wohl noch deutlich Vernichtender sein als selbst Intels Darstellung

 

[Stefan Payne]

Nur eines noch:
Wenn Spectre2 auf AMD funktionieren würde, dann hätte intel das schon längst rausgefunden und auch veröffentlicht.

EBEN!
Und alles, was wir seit Spectre/Meltdown bekommen haben, war irgend ein Bullshit, den die Intel Fans als Exploit verkafen, der System Zugriff voraussetzt bzw Admin Rechte. Und dann kann man da theoretisch was flashen und das Gerät ownen. Dabei besteht natürlich die Möglichkeit, dass man das Gerät zerstört oder anderweitig unbrauchbar macht. Aber hey, theoretich ist das möglich.

Ja, theoretisch kann ich auch 'nen "falsches BIOS" für den RAID Controller flashen und den ownen.
Theoretisch kann ich auch 'nen "falsches BIOS" für die Grafikkarte flashen und das ownen. Gut das haben die meisten Server nicht wirklich.

Aber das ist einfach nur ein Haufen gequirlter Scheiße, die hier sinnlos an Wände geschmissen wird, um zu schauen, was hängen bleibt.


Und du, lieber Iscaran, verteidigst einfach nur Intel bis aufs Blut, redest Intel schön und AMD schlecht. Das ist, was man allgemein als FUD bezeichnet. Denn DU kannst deine Behauptung, dass AMD betroffen ist, nicht belegen.

AMD selbst sagt, dass sie Access-Checks in der CPU implementiert haben, die Spectre/Meltdown vermindern. Warum erwähnst du das dann nicht?!

Und ohne Proof of Concept kannst du deine Haarspalterei stecken lassen.
Beweise doch endlich mal, dass das auch auf AMD funktioniert!
Denn, wie hier richtig erwähnt, wenn es kein POC gibt, gibt es keine Lücke.
Und ein Exploit, der eine Wahrscheinlichkeit von 50% hat ein richtiges Ergebnis zu liefern, ist nutzlos.

Denn genau DARAUF läuft es doch hinaus, dass es möglich sein könnte, die Exploits auf AMD zu nutzen, die Wahrscheinlichkeit eines erfolgreichen Explots aber total im Hintern sind, so dass das kein richtiger Exploit ist!
Du BRAUCHST hier eine Erfolgswahrscheinlichkeit von 90% oder mehr.
Wenn wir hier schonv on 70% sprechen, sind wir schon im Bereich des Auswürfelns.

 

[eratte]

Intel erklärt Hardware-Schutz gegen Spectre- & Meltdown-Lücken (heise)

 

[eratte]

Microcode-Updates: Intel hat Lizenzhinweis ausgetauscht (au-ja)

Und schon wieder:
Microsoft legt AMD-PCs mit Intels Microcode-Update lahm (au-ja)

 

[Stefan Payne]

Entweder sind die völlig inkompetent, nachdem die den Groteil der Tester gefeuert haben oder aber das ist Absicht, um AMD zu schaden.

 

[Casi030]

Natürlich ist das Absicht , mit ihren Fake Benchmarks sind sie auch nicht durch gekommen,irgend wie muss Intel ja wieder Trixen um besser zu werden.

 

[eratte]

Das ist aber für mich eindeutig Unfähigkeit von MS.

 

[eratte]

Intel's Whiskey Lake Brings In-Silicon Meltdown and Foreshadow Fixes (tom's Hardware)