DKK007 schrieb:
Worin genau besteht diese "non-default configuration" und wann liegt diese vor?
Tja, solche Details werden halt eben leider nicht genannt...
![Zwinkern ;) ;)](/forum/styles/smilies/wink.gif)
Müssen wir mal die kommenden Tage abwarten, bis es da mehr Details zu gibt.
Auch in dem Whitepaper gibt es einen Absatz wo geschrieben wird AMD sei betroffen von Variante 1, aber es wird nicht gesagt, unter welchen Umständen.
Aller Wahrscheinlichkeit nach sind diese ja genauso wie bei der "
AMD PRO CPU" so praxisfern, dass man es bei AMD Ryzen schon mit Absicht herbeiführen muss?
Das Fazit lässt jedenfalls vermuten, dass die Verfasser des Whitepapers selber denken, dass AMD-Prozessoren "in the short term" geschützt sind.
Es ist halt so,
alles was heute sicher ist, wird irgendwann mal unsicher sein.
Auch die sicherste Verschlüsselungsmethode, die wir heute verwenden wird "irgendwann" mal easy gehackt werden. Das ist halt der Gang aller Dinge.
Aber das ist ja dennoch kein Grund sie **heute** nicht zu verwenden.
Weil heute ist sie halt eben sicher.
So wie eben der Ryzen auch sicher ist.
Von daher ist es schon etwas übers Ziel hinaus geschossen, wenn man dann so tut als sei auf einen Schlag der Ryzen auch "betroffen".
Ist er halt nicht!
So wie ich es verstanden habe wurde nur ein versuch mit einer Ryzen PRO CPU gemacht und sie wurde absichtlich falsch konfiguriert (nondefault, wird auch nicht weiter erklärt), damit man sie "hacken" konnte.
Hätte man sie normal verwendet wäre dies nicht möglich gewesen.
Wie gesagt, unter dieser Bedingung finde ich es reichlich manipulativ, AMD-CPUs auf eine Stufe mit den unter normalen Umständen wirklich verwundbaren Intel-CPUs zu stellen.
Im Fazit rudern sie ja dann auch wieder zurück und schreiben Ryzen hat ein erheblich komplexeres Sprungverhalten
"AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based on past runs” [3, 5], implying even more complex speculative behavior. As a result, while the stop-gap countermeasures described in the previous section may help limit practical exploits in the short term, "