News CPU-Sicherheitslücken: Mehrere neue Spectre-Varianten, Meltdown trifft AMD

[new Account()]

Der Homeuser ist sehr wohl betroffen, und zwar in dem man Webdienste, Onlineshops, Cloud-Speicher etc. nutzt.

Trotzdem irrelevant: nicht du, sondern die Betreiber Der Dienste haben die Sicherheit Der Daten zu gewährleisten.

 

[neofelis]

Danke an alle, die das Problem hier differenzierter auflösen! Werdet bitte nicht müde dies auch weiterhin zu tun!

Die Überschrift des Artikels könnte auch direkt von Intel stammen, denen die Strategie der Zurschaustellung einer Alternativlosigkeit am Markt natürlich entgegen kommt.

AMD verhält sich doch ziemlich ruhig. Naja werben mit dem Slogan "Kaufen Sie bei uns, denn da gibts WENIGER Sicherheitslücken" kommt auch nicht sehr gut.
Außerdem, wenn sie jetzt anfangen würden zu prahlen, dann könnten sich die ganzen Enthüllungs-Großhirne vorrangig AMD vorknöpfen.

 

[5@n!töt3r]

Es gibt einen Haufen neuer möglicher Angriffspunkte und in den Titel schafft es jener Hersteller, der seltener betroffen ist. Hut ab!

 

[Iscaran]

@Iscaran
Ein paar Fragen hätte ich: Wie einfach ist es denn nun durch beispielsweise Spectre oder diese neuen nicht Cross-CPL fähigen Meltdown Exploits auf den Userspace einer anderen VM zuzugreifen, die auf der gleichen Hardware läuft. Braucht es für solche Zugriffe zwischen unterschiedlichen VMs Kernelspace Access oder reicht Userspace Access. Ist mir bislang nicht wirklich klar geworden.

Ich würde mal sagen mit nicht-CPL fähigen Exploits kannst du unmöglich aus der VM ausbrechen. Also aus eben genau deinem "userspace". Es sei denn du kombinierst das noch mit einer anderen Lücke aber das kann man ja immer machen.

Daher sind die CPL-Meltdowns halt auch echt eine andere Stufe bzw. eben so ein "Hammer".

Und Nebenschauplatz. Wie verhalten sich eigentlich Systeme in denen die einzelnen Kerne keinen shared Cache haben. Beispielsweise alte Athlon Systeme. Das waren ja um Prinzip noch zwei/vier dedizierte CPUs auf einem Silizium, die sich nur den Speichercontroler geteilt haben. Oder bringt es sicherheitstechnisch Vorteile, die VMs auf einem beispielsweise Epyc System einzelnen CCX zuzuordnen. (rein als theoretische Überlegungen)

Das kannn ich dir ehrlich nicht sagen - aber im Grunde erschwert es natürlich den Zugriff auf daten im Cache eines anderen Kerns wenn der Cache explizit ja "nicht"shared ist denke ich....
Aber da muss ich passen.

Was die VMs auf Epyc betrifft. AMD ist nur von Meltdown-BR "betroffen" (alias Spectre v1.2) dieser kann da kein CPL-Crossing ermöglicht wird unmöglich über den Userspace hinaus irgendetwas lesen. Auch nicht aus einer VM in die andere und daher vermutlich egal für Epyc ob man die VMs CCXen zuordnet oder nicht.

Anders der Fall beim Foreshadow L1TF - genau deswegen hat man ja das SMT (bzw. Hyperthreading deaktiviert ;-)).

 

[Ned Flanders]

@Iscaran

Ja, das ist irgendwie sehr schwer zu beurteilen ohne wirklich Zeit zu investieren. Eigentlich sollte das nicht gehen. Eigentlich sollten sich bei einem vier Chip Epyc auch mindestens vier VMs installieren lassen, die sich eigentlich nur den Sockel teilen, aber keinen Cache und auch keinen Memory Controler. Oder acht die sich zumindest den Cache nicht teilen (was ja das bevorzugte Szenario ist).

 

[Cool Master]

Trotzdem irrelevant: nicht du, sondern die Betreiber Der Dienste haben die Sicherheit Der Daten zu gewährleisten.

Aber du bist bei einem Leck am Ende betroffen, nicht die Betreiber. Die Betreiber können nicht mehr machen als neue FW auf die Boards spielen und das wars. Wie gesagt man muss Intel als auch AMD das immer wieder aufzeigen damit die in die Pötte kommen und für alle Produkte ein Patch brigen.

 

[new Account()]

Und was soll ich am Ende Machen? Alle online Dienste meiden?

Die Betreiber könnten im Notfall dafür sorgen, dass einer CPU nur Dienste eines online Anbieters zugeordnet sind, sodass sich dieser maximal selbst ausspähen Kann.

 

[(-_-)]

Und trotzdem sammelt Intel fleißig die "Sternchen im Hausaufgabenheft"

 

[Cool Master]

Und was soll ich am Ende Machen? Alle online Dienste meiden?

Nein. Bewust mit deinen Daten umgehen ergo nur das Online stellen was du jedem fremden mitteilen würdest und für jeden Dienst ein Zugang haben.

 

[anexX]

"Bisher hieß es, dass AMDs Prozessoren von den Meltdown-Sicherheitsproblemen gefeilt sind "

@Volker - das sollte wohl "gefeit" heissen denn "gefeilt" wird nur in der Werkstatt.

 

[psYcho-edgE]

denn "gefeilt" wird nur in der Werkstatt.

oder im Nagelstudio

 

[cbtestarossa]

Die grundsätzliche Frage lautet nun:
Wie konzipiert man eine CPU und ein OS damit solche Probleme in Zukunft gar nicht mehr auftauchen können.

1. Müsste man dann auf "HT/SMT" und "Out-of-order execution" komplett verzichten?
2. Wäre die Trennung der Speicherbereiche wie bei der Harvard-Architektur ein Vorteil?
3. Würden viele Kerne einen Sicherheitsvorteil bringen? So etwas wie "Xeon Phi" zB.

 

[Miuwa]

x86 und dessen Alter.

Hat absolut garnichts mir dem Befehlssatz zu.

Sieht man schon daran, dass einerseits sowohl ARM als auch x86 CPUs betroffen sind und es andererseits signifikante Unterschiede zwischen den CPUs verschiedener x86 Hersteller gibt.

 

[kisser]

Sieht man schon daran, dass einerseits sowohl ARM als auch x86 CPUs betroffen

IBMs PPC auch, aber die spielen derzeit wohl keine große Rolle mehr.
Die Probleme sind begründet durch
- spekulative Ausführung
- out of order Ausführung
- von Neumann-Architektur

Ergänzung (17. November 2018)

AMD ist nur von Meltdown-BR "betroffen" (alias Spectre v1.2)

Nicht verwechseln!

Spectre 1.2 ist Meltdown-RW und davon ist AMD nicht betroffen.

 

[MIWA P3D]

So bezeichnen die Forscher nun die Lücke Meltdown-RW (Read-only Bypass), welche zuvor als Spectre V1.2 bekannt war.

Genau wie Kisser sagt ^^

Zumindest aber Cloud-Anbieter mit AMD-Hardware können recht unbesorgt weiterarbeiten, ein Ausbruch aus dem Userspace in den Kernelspace ist nach Auffassung der Forscher bei deren Prozessoren nicht möglich.

 

[rob-]

Hat absolut garnichts mir dem Befehlssatz zu.

Sieht man schon daran, dass einerseits sowohl ARM als auch x86 CPUs betroffen sind und es andererseits signifikante Unterschiede zwischen den CPUs verschiedener x86 Hersteller gibt.

Man könnte auch sagen, hätten sie nicht voneinander kopiert.... oder zumindest den Teil kopiert, der nicht zur Lücke führt

 

[Miuwa]

Die Probleme sind begründet durch
- spekulative Ausführung
- out of order Ausführung
- von Neumann-Architektur

Was hat die von Neumann-Architektur damit zu tun?

 

[TornA]

Hat absolut garnichts mir dem Befehlssatz zu.

Alles klar, dann habe ich tatsächlich, wie von mir vermutet, Dinge miteinander vertauscht, die nicht zusammengehören. Wie ich sagte, ich strotze da nur vor halbfalschem Halbwissen.

 

[kisser]

@Miuwa

Einheitlicher Speicher für alles. Bei strikter Trennung in Daten- und Befehlsspeicher kannst du keine fremden Daten abgreifen, weil du deren Speicherbereich überhaupt nicht siehst.

 

[dMopp]

https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=
Sowas erwähnt CB natürlich nicht. MEGA HEFTIG!