Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSpectre: Details zu Microcode-Updates für CPUs von AMD
Ja, nVidia hat hier natürlich sehr viel mit zu tun.
Fakt ist, für AMD gibt es keinen PoC, nirgends, da muss man weniger die genaue Funktionsweise der Sicherheitslücken kennen, noch sonstige. Alle anderen Behauptungen entspringen wohl eher der blauen Fanboy-Brille... wie du so schön sagst.
Entschuldige, den Farbwechsel von grün nach schwarz beim AMD-Logo hatte ich nicht mitbekommen.
Aldaric87 schrieb:
Fakt ist, für AMD gibt es keinen PoC, nirgends, da muss man weniger die genaue Funktionsweise der Sicherheitslücken kennen, noch sonstige. Alle anderen Behauptungen entspringen wohl eher der blauen Fanboy-Brille... wie du so schön sagst.
Hast du nicht damit begonnen mit irgendwelchen Fanboy-Brillen um dich zu werfen in deinem Post? Obwohl du die Faktenlage ja selbst kennst?
Interessant was für eine verzerrte Wahrnehmung du hast. Deinen eigenen Post als *neutral* zu bezeichnen, aber Leuten die etwas anderes sagen unterstellst du dann die "grüne Fanboybrille". Aber ja, sehr neutral.
Sie haben auch Exploits auf anderen Systemen zum laufen gebracht..auch auf einem Bulldozer wenn man den non-default state benutzt. Allein die Tatsache dass sie mit solchen non-default state rumgespielt haben zeigt doch meines erachtens nach wieviel sie hier versucht haben. Und die haben bestimmt AUCH Ryzen versucht - aber sie haben sich gehütet ein negatives Resultat offenzulegen. (EDIT: und selbst das mit dem non-default state betrifft ja nur den Spectre v1 stelle ich grad nachträglich nochmal fest)
Der Grund dafür ist einfach....wenn ich irgendwo zu "100%" sicher behaupte dass etwas nicht geht, bin ich in der Bredouille falls es doch klappt. Deswegen geben sowohl die Spetre-Leute der TU Graz (PDF) als auch das GPZ-Team nur Infos raus zu Exploits welche diese zum Laufen gebracht haben !
Schlimmer als ein False Positive ist ein False Negative - deswegen gibt es nirgendwo in der Security Branche Seitenweise Testaussagen mit....XYZ geht NICHT!. Immer findet man nur Belege der Form XYZ GEHT auf System ABC.
Deswegen kann man auch nicht "belegen" was wie wer wieviel ausprobiert hat.
EDIT: Grundsätzlich kann es wegen der OoO-Architektur aber sein dass man doch noch Wege und Möglichkeiten findet das auch auf anderen CPUs wirklich zu "exploiten".
Für AMD nicht und das auch 1 Monate NACH veröffentlichung der anderen Exploits. Ist offenbar also nicht so leicht die Methode auf die AMD-Archs abzuwandeln...warum steht oben.
Allgemein irgendwie lustig, wie sich die Leute hier versuchen gegenseitig den schwarzen Peter zuzuschieben, um damit AMD oder Intel besser dastehen zu lassen.
Und selbst, wenn die Lücke bei AMD wirklich nicht ausgenutzt werden kann und AMD nicht nur Glück hatte, da sie u.U. einfach nur die rückständigere CPU-Architektur hatten, statt wirklich so sehr auf Sicherheit auszusein.
Dann freut Euch halt mal heftig. Aber dann ist doch auch irgendwann mal gut.
Dein Post war interessant, bis ich das Wort "rückständigere" lesen musste. Damit war auch dieser Post wieder für die Tonne.
(Ich finde Intel's Produktion rückständig, weil die nicht mal verlöten sondern nur Ketchup zwischen DIE und IHS schmieren - ist hier in der Thematik genau so eine unnötige Aussage, wie die unnötige Behauptung die Arch von AMD wäre "rückständig". Denn Iscaran hat gut erklärt wieso es bei AMD anders ist als bei Intel. Das hat wenig mit Rückständig zu tun, sondern sind einfach Unterschiede, die vll. auch Patentbedingt vorhanden sind.)
Wie meinst Du das genau? Warum sollte AMD keine Intel Patente nutzen? Du weißt schon, dass Intel und AMD ein Patentabkommen da sihnen die gegenseitige Nutzung erlaubt?
Außerdem hab ich dir im anderen Thread schon belegt, dass der Gruss von der TU Graz die Architektur als simpel / einfach bezeichnet hat... Du kannst nicht einerseits sagen, die Forscher haben nicht gefunden, yeah die Forscher haben recht, und dann wenn die Forscher sgaen AMD hat eine einfach Technik, "die haben keine ahnung"...
@rg88
Natürlich kann man als neutraler Mensch sagen dass jemand Fanboy ist. Ich bin auch neutral und Aldaric ist der Prototyp von nem Fanboy...
Ich würde eher sagen "weniger fortschrittlich" (im Hinblick auf die Leistung), da eben Techniken nicht genutzt werden, durch die Intel teilweise große Geschwindigkeitsvorteile erzielen konnte.
Inwiefern da Sicherheitsrisiken für in Kauf genommen wurden, ist wieder eine andere Sache, über die sich streiten lässt.
Ich würde eher sagen "weniger fortschrittlich" (im Hinblick auf die Leistung), da eben Techniken nicht genutzt werden, durch die Intel teilweise große Geschwindigkeitsvorteile erzielen konnte.
Die aussage ist leider genauso falsch. Wenn die Geschwindigkeitsvorteile bei Intel genau dadurch zustande kamen dass man sich ein paar CPU Zyklen gespart hat um eine Rechteprüfung des Prozesses zu vermeiden (Stichwort Meltdown) oder den Cache-Durchsatz "leicht" erhöht hat in dem man nur unvollständige Adressbereiche speichert (und damit "wichtigen" Cache-Space nicht zu belegen) finde ich nicht unbedingt dass das "fortschrittlicher" ist...
Aber um DAS wirklich beurteilen zu können verstehe ich zuwenig von CPU-Design.
Fakt ist Worte wie "rückständiger" etc zu verwenden ist in dem Kontext einfach verkehrt.
Die CPU-Archs sind verschieden, WEGEN der Verschiedenheiten ist AMD hier aktuell weniger anfällig...ob das nun Zufall war/ist oder "design" kann außer einem Jim Keller und Team eh keiner sagen.
Ähm, euch scheint nicht ganz klar geworden zu sein, dass ich mit meinem oberen Beitrag eigentlich nur die beiden Extrempositionen etwas ad absurdum führen wollte.
Aber gut, dann macht mal schön so weiter und legt jedes Wort auf die Goldwaage.
Wie erklärst du dir das?
Du solltest dich vielleicht mal mit Aussagenlogik beschäftigen, denn das etwas nicht erwähnt wird, bedeutet nicht, dass es nicht existiert, während hingegen im Umkehrschluss die Tatsache, dass etwas erwähnt wird, definitiv heißt, dass es existiert.
Aus A folgt B heißt nicht, dass aus nicht-A auch nicht-B folgt.
Ergänzung ()
rg88 schrieb:
Die Lücke besteht potentiell bei jeder CPU die nach diesem Prinzip arbeitet.......... Aber ob man es auch schafft die auszunutzen ist was anderes.
Es hat aber (außer AMD) niemand behauptet, dass dies "schwierig" wäre, wobei deren Aussage von "near zero risk" aber absolut unbrauchbar ist! Kann man das in Prozenten oder als Verhältnis ausdrücken, wie man das gemeinhin mit Risiken/Chancen macht?
Was soll "near zero" bedeuten? 1? 2? 10? 1000?
Ergänzung ()
DFFVB schrieb:
Aber um es nochmal anders zu sagen: Man weiß es bzgl AMD schlicht nicht... ja es gab keine Exploits, man weiß aber nicht wieviel hier probiert wurde...
These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.
[1.3 Targeted Hardware and Current Status] - Herstellerübergreifend
We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs. Similar results were observed on both 32- and 64-bit modes, and both Linux and Windows. Some ARM processors also support speculative execution [2], and initial testing has confirmed that ARM processors are impacted as well.
Tests, primarily on a Haswell-based Surface Pro 3, confirmed that code executing in one hyper-thread of Intel x86 processors can mistrain the branch predictor for code running on the same CPU in a different hyper-thread. Tests on Skylake additionally indicated branch history mistraining between processes on the same vCPU (which likely occurs on Haswell as well)
Das sind die Fakten, die sich aus dem Dokument ergeben. Mehr braucht man dazu nicht zu sagen. Dass in dem Kapitel zu PoC für spectre V2 kein anderer Hersteller erwähnt wird bedeutet nur, das man über diese keine Aussage treffen kann.
Das sind die Fakten, die sich aus dem Dokument ergeben. Mehr braucht man dazu nicht zu sagen. Dass in dem Kapitel zu PoC für spectre V2 kein anderer Hersteller erwähnt wird bedeutet nur, das man über diese keine Aussage treffen kann.
Das ARM Whitepaper vom 19.01.2018 das ich gerade gefunden habe ist hier auch interessant weil es deutlich mehr details zu den Angriffswegen ausgibt https://developer.arm.com/support/security-update/download-the-whitepaper
Jeweils die Kapitelchen "Practicality of this attack" für V1, V2, V3, V3a
All PoCs are written against specific processors and will likely require at least some adjustments before they can run in other environments, e.g. because of hardcoded timing tresholds.
Korrekt sofern du damit v2 Spectre meinst. V1 geht "relativ simpel" auf nahezu allen Spekulativen Archs. Auch solchen die NUR in-order arbeiten ! (Power IBM z.B. !)
Ja...er schreibt ja dann auch weiter: https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=317456
"I'm going to send a short notice about this to ARM and AMD later today, but I don't intend to send them the full PoC, since I think it's quite Intel-specific."
Das bezieht er auf den Spectre v2 PoC.
Korrekt sofern du damit v2 Spectre meinst. V1 geht "relativ simpel" auf nahezu allen Spekulativen Archs. Auch solchen die NUR in-order arbeiten ! (Power IBM z.B. !)
So ganz einfach ist das dennoch nicht, weil da selbst einzelne Compileroptionen zwischen vollständigem Erfolg und komplettem Versagen entscheidend sind:
Er ist leider nicht sehr spezifisch damit was er unter "Spectre" versteht - aber wenn ich den GitHub code auf den er verweist richtig interpretiere dann bezieht er sich darin auf Spectre V1.
Spectre V1 ist ja auch der Exploit den nahezu ALLE CPUs betreffen sollten (die Speculative//OoO-Execution benutzen)
Das interessante ist dass Spectre V1 PoCs aber AUCH auf CPUs funktionieren die EIGENTLICH strikt in-order arbeiten (aber hier dennoch speculative Executions zulassen....wie eben die Power PCs speziell Power 6 https://en.wikipedia.org/wiki/POWER6
"A notable difference from Power5 is that the POWER6 executes instructions in-order instead of out-of-order."
=> Hierauf bezog ich den Link von David Schor.
EIGENTLICH sollte der Spectre V1 hier nicht funktionieren. Tut er aber eben DOCH !
Ja das bezieht sich auf spectre V1.
Selbst dieser "einfache" PoC liefert ganz unterschiedliche Ergebnisse. Es ist mir trotz stundenlangen Kompilierens und ändern von Parametern noch nicht ein Mal gelungen, die Zeichenkette vollständig auf meinem Q9400 zu rekonstruieren.
Selbst bei 10 Durchläufen mit dem gleichen Kompilat habe ich 10 unterschiedliche Ergebnisse (wo jeweils nur einzelne Zeichen korrekt sind).
Die besten Ergebnisse habe ich, wenn während des PoC-Laufes die CPU anderweitig ausgelastet ist (z.B. Laden einer Website in Firefox). Das ist halt alles nicht so einfach mit diesen Timing-Messungen.
Mein bestes Ergebnis bisher (fehlerhaft = blau, nicht alle Treffer als Success gekennzeichnet):
Ja stimmt. Das war aber Anfang Januar so noch nicht klar. Selbst die Entdecker von Spectre V1 meinten ja es wären nur OoO speculativ arbeitende Archs anfällig.
Nun zeigt sich aber dass de-facto alle Archs seit ca. 1995 für V1 potentiell anfällig sind.
Ja, kann sein dass der 9400 halt nicht "tief" genug spekuliert, wenn die CPU-Last so gering ist dass er quasi alle befehle "in-order" schafft ? Oder der Yorkfield ist eben nicht ganz so anfällig dafür ?
Hast du nicht was neuereres als so eine alte Mühle das ist ja noch nicht mal Core2 :-)?
EDIT: Spectre V2 braucht schon Out of Order...Speculative Out of order um genau zu sein. Sonst würe man ja nicht den Branch predictor "trainieren" müssen für V2.
Hab leider nichts neueres als den Q9400. Aber das ist schon ein Core2.
Mittlerweile hab ich auch einen Lauf mit vollständiger Rekonstruktion (wieder mit Prime95 "Blend", die anderen Tests helfen nicht!) hinbekommen.
Habe hier auch noch einen Atom N455 (in-order), derzeit absolute Fehlanzeige bei der Rekonstruktion.
Kann aber auch keine speculative execution laut https://en.wikipedia.org/wiki/Intel_Atom
This enables relatively good performance with only two integer ALUs, and without any instruction reordering, speculative execution, or register renaming.
Ja, kann sein dass der 9400 halt nicht "tief" genug spekuliert, wenn die CPU-Last so gering ist dass er quasi alle befehle "in-order" schafft ? Oder der Yorkfield ist eben nicht ganz so anfällig dafür ?
"in-order" schaffen gibt es bei OoO nicht. Man will durch OoO ja die Abhängigkeiten (pipeline stalls) der Befehle auflösen, da wird immer umsortiert, unabhängig von der CPU-Last. Der Erfold der side-channel attacke steht und fällt allein mit der Timing-Präzision (-> feststellen, welche Daten in den Cache geladen wurden während der speculativen execution).
Ich vermute, dass Prime "Blend" so viel RAM und Cache nutzt, dass die vom spectre PoC in den Cache geladene (=angegriffene) Speicherzelle recht eindeutig indentifizierbar ist. Diese stammt ja im Falle des PoC aus seinem eigenen Adressraum.
