News Ryzen und Epyc: Sicherheitslücke betrifft alle aktuellen AMD-Prozessoren

[Denniss]

Einige/viele scheinen sich daran zu stören das das Entdeckerteam von Intel "gesponsort" wird.
Die haben auch genug Lücken bei Intel gefunden so daß dort wohl keine Blindheit auf einem Auge vorliegt.

 

[Dahaka92]

Lest ihr die News eigentlich bis zum Ende? Die Lücke ist eigentlich keine Lücke, mit den Metadaten lässt sich nahezu gar nichts anfangen.

Die CPUs von AMD sind immernoch bei weitem sicherer.

 

[xpac]

Konnte man jetzt mit rechnen das es Probleme geben wird in den CPUs von AMD. Wie hier schon wer schrieb, wer suche der finde was ich persönlich super finde das Forscher sich das alles anschauen und bescheid geben.

Intel hat seine AMD ihre eignen Probleme, alles wie zu erwarten. Für einige scheint diese einfache Erkenntnis ja den Weltuntergang zu bedeuten. Gut ist Samstag, manchen ist wohl schlicht langweilig. Go Go Fanboys!

 

[Draco Nobilis]

Da liegt ja aber genau auch das Problem- Meltdown und Zombieload liefern ja eher zuviele, dafür völlig inkonsistente Daten. Damit kannst Du sämtliche Bussysteme killen.

LG
Zero

Mich interessiert, ob man mit dieser Lücke, bei AMD effektiv, vlt. auch in Kombination mit anderen Maßnahmen das System übernehmen, signifikantent Daten stehlen, komprimitieren, beschädigen und / oder abstürzen lassen kann und ob es auch vom Opfer überhaupt bemerkt werden kann.
Bei Intel ist die Frage nicht gegeben, da ist es bekannt.

 

[.Sentinel.]

Mich interessiert, ob man mit dieser Lücke, bei AMD effektiv, vlt. auch in Kombination mit anderen Maßnahmen das System übernehmen, signifikantent Daten stehlen, komprimitieren, beschädigen und / oder abstürzen lassen kann und ob es auch vom Opfer überhaupt bemerkt werden kann.

Genau das zu klären, wären die nächsten Schritte. Lassen sich mit den gewonnenen Metadaten gezielt Zweitangriffe beschleunigen...bzw. lässt der Zugriff auch andere Angriffsvektoren zu.

Wenn ja werden wir demnächst wie bei Intel diverse Ausführungen zu Komplemantärangriffen auf das selbe Fehlerprinzip sehen (was oftmals bei dem User fälschlicher Weise oft als "neue" Lücke interpretiert wird).

LG
Zero

 

[andr_gin]

Sind wir mal ehrlich - wer kauft eine CPU anhand irgendwelcher Sicherheitslücken ?!

Für mich waren vor allem folgende Argumente ausschlaggebend:

• Preis
• Sockel / Chipsatz "Zukunft"
• viele Kerne (wollte einen ordentlichen Schub machen vom i7 Quad und Kerne mindestens verdoppeln)

Da diese Lücken bisher alle nur Betreiber von Cloudsystemen betroffen haben (mit Ausnahme von Spectre V1) spielt dies aus Sicht der Sicherheit keine Rolle auf privaten Spielerechnern.

Sobald aber alle User mit performancesenkenden Microcodeupdates zwangsbeglückt werden ist das sehr wohl für alle relevant.

 

[Cool Master]

Jeder AMD Fan in den letzten 2 Jahren also?

Pauschalisiere doch nicht so... Viele trollen auch einfach nur oder meinen jeder würde den Sarkasmus erkennen. Wie schon gesagt wurde ich finde es gut wenn die Lücken auftauchen und die Hersteller darüber informiert werden. Nur so können bessere Produkte kommen sei es von ARM, Intel oder AMD.

Wie gesagt es wird niemals ein 100% sicheres System geben. Das wichtige ist wie geht AMD nun mit den Erkenntnissen um, wann ein fix kommen wird und wenn er kommt ob er die Leistung beeinflussen wird.

 

[RaptorTP]

@andr_gin

natürlich geht dann ein wenig Leistung drauf.

Bisher macht ja AMD noch das Rennen in "weniger Sicherheitslücken"
Ist aber, da bin ich ganz ehrlich, nicht mein Kaufkriterium

ich setzte nen fixen Takt & Voltage und verliere da auch ein wenig Leistung - habe aber dadurch eine sehr sparsame und leise kühlbare CPU

 

[Teralios]

Es war zu erwarten, dass auch bei AMD entsprechenden Lücken gefunden werden.

CPUs sind heute so komplex, dass man dort keine hundertprozentige Sicherheit erwarten kann. Genau so kann man bei Software keine hundertprozentige Sicherheit erwarten.

Selbst wenn man einzelne Bestandteile als Sicher verifizieren kann, ist es spätestens ab einem Zusammenspiel der Bestandteile nicht mehr so.

Ich bin gespannt, um was für eine Lücke es sich nun bei dem L1D handelt und wie sich dieser ausnutzen lässt, davon hängt auch ab, ob er per Software eliminiert werden muss, per Micro-Code und ob es mit Leistungseinbußen verbunden ist oder nicht.

Mal abwarten, was da kommt.

Wie AMD ja selbst schon schrieb. Da wird wohl jemand den L1D cache neu erfinden müssen.

Kommt darauf an, was nun genau das Problem ist. Neu erfinden ist nicht unbedingt notwendig, wenn es auf gewisse Art passiert.

RISC-V... oh wait sie wollen ja vermutlich etwas mit dem PC machen. Wobei mit Linux geht auf RISC-V schon einiges.

Falsch, und zwar sowas von.

RISC-V ist erst mal nur eine ISA und die reine ISA kann man zwar mit gewissen Grundsätzen von den Befehlen her sicherer gestalten, am Ende hängt es jedoch von der Hardwareimplementierung ab wie sicher die CPU ist.

Und erst recht ist RISC-V nicht gegen unsichere Implementierungen von Caches usw. gefeit und solche Probleme werden auch nicht durch eine an sich sicheren ISA abgefangen.

Ich bin ja gespannt, wie viele noch damit kommen, dass RISC-V sicher ist, obwohl es nicht stimmt.

Wie bei x86, wie bei PowerPC oder ARM, hängt die Sicherheit der CPU nicht von ihrer ISA ab, sondern davon wie diese implementiert wurde.

 

[DarkerThanBlack]

Ich frage mich gerade ernsthaft warum man hier so eine große Aufmachung wegen dieser irrelevanten Lücke macht?

Laut Analyse handelt es sich nur um Metadaten welche nicht zu gebrauchen sind.
Ist so, als ob man bei einem Haus die Fenster zählt auch wenn sie einbruchssicher sind und man nicht einsteigen kann.
Ist wohl auch der Grund warum AMD nicht groß darauf reagiert hat, weil die Sicherheit eben auch weiterhin gewährleistet ist.

Aber hey, jetzt hat man ja was womit man den Finger auf AMD zeigen kann gelle?

 

[AlphaKaninchen]

Falsch, und zwar sowas von.

RISC-V ist erst mal nur eine ISA und die reine ISA kann man zwar mit gewissen Grundsätzen von den Befehlen her sicherer gestalten, am Ende hängt es jedoch von der Hardwareimplementierung ab wie sicher die CPU ist.

Und erst recht ist RISC-V nicht gegen unsichere Implementierungen von Caches usw. gefeit und solche Probleme werden auch nicht durch eine an sich sicheren ISA abgefangen.

Wie bei x86, wie bei PowerPC oder ARM, hängt die Sicherheit der CPU nicht von ihrer ISA ab, sondern davon wie diese implementiert wurde.

RISC-V gibt es aber zumindest theoretisch als Open Source Implemmentierung, meine eigene Meinung dazu ist Open Source in Hardware ist toll zum Basteln bezüglich Sicherheit hat es aber das Problem das man nie Prüfen kann ob das im Chip ist das drin sein sollte. Und bei Lücken in z.B. der ME würde auch ein Open Source CPU wo exakt das drin ist das draufsteht nicht helfen. Des weiteren gibt es Implemmentationen die behaupten Angriffe Blocken zu können wie z.B. Morpheus was da am Ende dran ist halte ich aber für fraglich.

 

[Ben81]

Aber hey, jetzt hat man ja was womit man den Finger auf AMD zeigen kann gelle?

Funktioniert anderst herum doch auch super, oder? Wir wollen doch "fair" bleiben.

 

[ghecko]

Du weißt aber schon dass der Satz Seiten vorher ironisch gemeint war?

Teils teils. Lieber Wissen streuen als Unwissen stehen lassen. Auch wenn es vllt nur für ein paar andere danach aussieht.

Kommt darauf an, was nun genau das Problem ist. Neu erfinden ist nicht unbedingt notwendig, wenn es auf gewisse Art passiert.

Um die ganze Funktionskette der Lücke zu unterbrechen muss man die decodierten Speicheradressen im cache way predictor bei jedem Zugriffswechsel auf einen anderen Prozesse zurücksetzen. Somit verliert man etwas Performance, weil in dem Fall die Daten aus dem L2D Cache nachgeladen werden müssen, aber es lässt sich durch die Zugriffszeit nicht mehr nachvollziehen, auf welche Adressen der andere Prozess zugegriffen hat. Da auf dieses Mapping alles weitere aufbaut wäre die Lücke gestopft.
Und für die nächsten Architekturen sollte AMD wohl verhindern, das ein invalider Zugriff auf einen Speicherbereich außerhalb des virtuellen Adressraumes überhaupt im cache way predictor den pointer auslöst. Invalid access = pointer rücksetzen. Letzteres muss aber wohl in Hardware implementiert werden.

 

[captain kirk]

Ich glaube alle Nutzer von aktuellen Prozessoren müssen sich damit arrangieren, dass kein Hersteller von einer langen Liste an Sicherheitslücken verschont bleibt, alles andere wäre eine Überraschung.
Mal schauen wie lange das "AMD ist sicherer" noch gilt, sobald deren Marktanteile, auch im Serverumfeld, steigen und sich demzufolge auch mehr Forscher auf dem Gebiet umsehen.

Genau das!

Das Grundproblem ist nämlich das es für Sicherheitsforscher bisher "attraktiver" um nicht zu sagen lukrativer war ,das Intel Öko System zu beackern.
Da werden sich noch einige hier den Mund verbrennen ,wenn der Fokus peu a peu Richtung AMD wandert , mit steigenden Marktanteilen

Da ist das hier erst der Auftakt , und bringt hoffentlich einige mal wieder auf den Boden der Realität zurück

 

[harrysun]

Ich ich dachte ich finde keinen Grund auf Zen 3 zu wechseln 😏

 

[Gewuerzwiesel]

Aber hey, jetzt hat man ja was womit man den Finger auf AMD zeigen kann gelle?

Naja das zeigt auf, dass beide Seiten nicht fehlerfrei sind, was auch logisch ist. Die Forscher jetzt deswegen, weil die Arbeit von Intel z. T. finanziert wurde, zu verurteilen ist in meinen Augen auch falsch.
Afaik ist es doch schließlich die Forschergruppe, welche Meltdown und Spectre aufgedeckt hat. Um das PR Fiasko abzumildern hatte Intel ihnen daraufhin Forschungsgelder zur Verfügung gestellt.
Für die Doktoranden macht es nun das Leben einfacher, da man sich nicht Jahr für Jahr um eine Finanzierung kümmern muss, wie es in dem Umfeld üblich ist.
Natürlich werden diese jetzt da AMDs Marktanteil zunimmt sich auch der Zen Architektur widmen...

 

[goldener Reiter]

Jetzt sind die AMD Fans aber in der Zwickmühle.
Habe sie ja erst gestern hier im Intel-Artikel wieder groß auf Intel gezeigt und was für tolle CPUs sie doch haben, und nun?

Müssen solche Fanboy Kommentare wirklich sein? Du machst genau das worüber du dich beschwerst.
Zumal die Probleme bei Intel nach wie vor deutlich gravierender sind, die letzten Fehler sind sogar angeblich gar nicht zu fixen.
AMD ist insgesamt immer noch deutlich sicherer, was im Auge der Verhältnisse der beiden Firmen eher für Intel peinlich ist und nicht andersrum. Schau dir die Geschäftszahlen und Mitarbeiter an, AMD ist nicht mal ein 1/10 von Intel.
Zumal der Artikel hier echt gut geschrieben ist, offenbart dieser doch das Intel wieder mit Geld Einfluss nimmt und somit auch Forscher entsprechend lenkt. Da wird jetzt massiv nach Problemen bei AMD gesucht um von Intel abzulenken. Hinter den Kulissen war das schon immer die Strategie von Intel, wenn es nicht lief. So etwas ist unlauterer Wettbewerb und jemand der schon mal verurteilt wurde und nachweislich lügt, dem glaubt man eh nichts mehr. Würde mich schämen wenn ich ein sogenannter Intel Fanboy wäre, wobei es die komischerweise aktuell eh nicht mehr gibt. Alle plötzlich verschwunden seit es technisch abwärts geht...

Mal ehrlich, wie groß kann der Zufall sein ein Tag nachdem es schlechte Publicity für Intel gab? Hm....

 

[TorgardGraufell]

Ist doch egal...ob Intel oder AMD........Kochen beide nur mit Wasser und bescheißen beide ,wie alle großen Firmen.!!

 

[goldener Reiter]

@TorgardGraufell
Ich möchte ungern Partei ergreifen, aber frag dich mal wo dich Intel oder AMD bei CPUs betrogen hat. Intel hat das bereits mehrfach getan, teilweise sogar für Benchmarks extra bezahlt in denen die Konkurrenz schlechter dasteht. Von den Gerichtsurteilen wegen unlauterem Wettbewerb, etc.... ganz zu schweigen.
Wenn selbst das schlechtere und teurere Produkt besser verkauft wird, stinkt etwas gewaltig. Und das war schon zu Zeiten des Pentium 4 so. Da nutzt eine Firma die gewaltige Marktmacht aus.
Schau dir einfach die Verhältnisse der Firmen an. AMD ist ein Furz finanziell und personell gesehen im Vergleich zu Intel.

 

[DerJungeDerIst]

Sagt die Intel - forschung?

Aha, die TU-Graz gehört also Intel oder soll steht ihnen exklusiv zu Diensten sein, das ist ja eine extrem unkundige Sichtweise.