News RETBleed: CPUs von AMD und Intel bleiben anfällig für Spectre V2

SVΞN

Redakteur a.D.
Registriert
Juni 2007
Beiträge
22.977
  • Gefällt mir
Reaktionen: flo.murr, flaphoschi, Rios und 13 andere
So richtig Geister ausmerzen können nur die Ghostbuster!
Es wird immer Lücken geben, gut dass sie aufgedeckt werden.

... Immerhin sind INTEL UND AMD betroffen, sonst wird hier wieder ein lustiger Thread 🙃
 
  • Gefällt mir
Reaktionen: flo.murr, niteaholic, Rockstar85 und 15 andere
@SVΞN Typo
Seid 2018 werden CPU-Familien wie AMD Ryzen 2000 gegen die Sicherheitslücken Spectre-V1 und -V2 gepatcht, bislang erfolglos.

War ja zu erwarten. Spectre und Konsorten sind ja ein strukturelles Problem, aber mittlerweile sind die Schwachstellen ja eher theoretischer Natur.
 
  • Gefällt mir
Reaktionen: NMA
Auch für heimanwebder wenn auch gering, trotzdem ein Grund mehr, warum ein Update sich lohnen kann, auch wenn viele Jahre bei cpu‘s wenig IPC Zuwachs gab.
Auf einen aktuellen Prozessor zu greifen wäre wohl an der Zeit mMn.
Und bald mit DDR5 vllt endgültig z.B. für Sandy Bridge und Bulldozer Nutzer auf was aktuelles zu wechseln
 
Was sind „Startlöscher“? :D
 
  • Gefällt mir
Reaktionen: domin95, tollertyp, Unnu und eine weitere Person
Wird wohl längere Zeit so bleiben. Wenn tatsächlich gefixt wird entdecken die Forscher eine neu Lücke...
 
  • Gefällt mir
Reaktionen: Hatsune_Miku
Chesterfield schrieb:
ein Grund mehr, warum ein Update sich lohnen kann, auch wenn viele Jahre bei cpu‘s wenig IPC Zuwachs gab.

Naja, ein guter Teil der IPC-Steigerung über die Jahre basiert ja genau auf der speculative execution, die uns das ganze Meltdown/Spectre-Gedöns erst eingebrockt hat :D
 
  • Gefällt mir
Reaktionen: n8mahr, flaphoschi, BorstiNumberOne und 2 andere
SVΞN schrieb:
Seid 2018 werden CPU-Familien wie AMD Ryzen 2000 gegen die Sicherheitslücken Spectre-V1 und -V2 gepatcht, bislang erfolglos.
Das stimmt so aber nicht Sven.
Die Sicherheitslücken werden und wurden nicht gepatcht. Gepatcht würde bedeuten, beseitigt, erledigt, verhindert. Dem ist aber nicht so!!
Es wurden Workarounds implementiert bzw. Mitigations eingebaut. Eine Mitigation ist keine Lösung - eine Mitigation ist eine Abmilderung des Problems. Idealerweise bis in den Zustand, dass es quasi unsinnig ist, über die Mitigation hinweg das Ziel anzugehen. Zumindest in manchen der neueren Modelle ist das auch so passiert. Einige dieser Mitigations sind nicht so wirksam - wie man hier auch sieht. Andere wiederum schon. Faktisch kostet das am Ende trotzdem irgendwo Leistung, weil man Aufgaben mit in die Abarbeitungskette einbaut, die eben Zeit kosten (können).

Das Ende vom Lied ist allerdings, gegen die Art von Angriffsvektoren sich vollständig zu schützen ist in der aktuellen Form sehr sicher ziemlich unmöglich, denn man nutzt einen vereinfacht gesagt, Umstand aus, bei dem der Prozessor exakt das machen soll, was man hier als Sicherheitslücke bezeichnet. Nämlich indem er schon Sachen macht, die er noch gar nicht machen sollte oder die er mit Fehlern quittieren würde, wenn sie nicht spekulativ in die Zukunft gemacht wurden wären. Das weg zu bekommen dürfte nahezu unmöglich sein unter Beibehaltung der spekulativen Ausführung und dem Out of Order Prinzip.



Was ich btw. bisschen interessant finde ist wie man mittlerweile bei der Thematik abgestumpft ist. So ne News in 2018 und mit gedrehten Vorzeichen bei der Datenmenge die auslesbar wäre - da wäre hier wieder sonstwas los...
 
  • Gefällt mir
Reaktionen: JackForceOne, Volvo480, Apple ][ und 7 andere
Eigentlich, einfach wie bei der Firewall....
jede Sicherheitseinstellung kostet leistung/durchsatz....

Wenn man das Ganze von der anderen seite betrachtet dann sind ja Prozessoren von Chinesen oder Russen
fast ebenbürtig, wenn man fertigungs Prozesse angleicht.
 
Dann bin ich mit meiner Zen 3 CPU erstmal vor retbleed "sicher"? Oder wurde es mit denen nicht getestet, was ich mir nicht wirklich vorstellen kann.
 
Ichtiander schrieb:
Eigentlich, einfach wie bei der Firewall....
jede Sicherheitseinstellung kostet leistung/durchsatz....

Wenn man das Ganze von der anderen seite betrachtet dann sind ja Prozessoren von Chinesen oder Russen
fast ebenbürtig, wenn man fertigungs Prozesse angleicht.

Wer sagt das die Chinesen/Russen Prozessoren sicherer sind ? Vielleicht haben sie genau die gleichen Probleme , vielleicht sogar unsicherer und generell andere Baustellen. Das weiss man einfach nicht. Nur ist Intel und AMD als beides große bekannte CPU Hersteller besonders im Fokus. Und AMD mittlerweile wieder, weil sie auch gut Marktanteile zurück geholt haben die letzten Jahre. Ich frage mich einfach nur wann bei Apple SOC und ARM basierenden CPU's die mittleren bis schwerwiegenden lücken entdeckt werden ^^.
 
@HAse_ONE

Wenn es kein Cloud Rechner ist schon. Die Lücke ist auf dem Desktops schwer ausnutzbar.. Stand in HeiseNews
 
@HAse_ONE nur Zen 1, Zen 1+ und Zen 2 sowie Core 6. bis 8. und noch ältere CPUs sind für RETBleed anfällig.

Aufgrund der Komplexität sind Privatanwender ohnehin nicht betroffen.
 
  • Gefällt mir
Reaktionen: n8mahr, Slayher666, BorstiNumberOne und 5 andere
Auf dem Windows-Gamer-PC würde ich mir deswegen keine Sorgen machen, da gibts jederzeit hundert andere, gefährlichere Sicherheitslücken, allen voran diejenge, die 80 cm vom Monitor entfernt sitzt.

Wer wirklich dauerhaft sicher gegen diese Art von Sicherheitslücke sein will, muss Hyperthreading/SMT deaktivieren. Dass die Cloud-Server-Anbieter das nicht wollen, ist aber auch verständlich.

Edit:
Wie xexex weiter unten ausgeführt hat, hilft gegen RETBleed leider auch das Deaktivieren von HT/SMT nichts.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: DFFVB und Unnu
@SVΞN
Es wäre wert zu erwähnen das die Kernel Patches die im Linux Kernel 5.19 by default aktiviert werden einen recht extremen Performance Unterschied machen.

Also hinter "Unter Linux bereits gepatcht" gehört definitiv ein dickes "Aber".
 
  • Gefällt mir
Reaktionen: DannyA4, Slayher666 und DFFVB
masterw schrieb:
Wer wirklich dauerhaft sicher gegen diese Art von Sicherheitslücke sein will, muss Hyperthreading/SMT deaktivieren.
Nö! SMT hat damit nichts zu tun und schützt gegen diese Angriffsart nicht. Man bräuchte CPUs die komplett auf eine Sprungvorhersage verzichten und am besten auch gleich auf jegliche Form von L3 Cache. Damit wären wir zurück in einer CPU Steinzeit angelangt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JackForceOne, br0da, rumpeLson und 2 andere
  • Gefällt mir
Reaktionen: GERmaximus und rumpeLson
Zurück
Oben