News Sicherheitslücken: OpenBSD warnt massiv vor Intels Hyper-Threading (SMT)

[Hill Ridge]

und bis auf Spectre V2 war bei AMD kein Microcode Update der CPU notwendig

Und selbst da war man eigentlich nie verwunbar.

Der Exploit war nur anwendbar, wenn man etwas im Kompiler aktiviert, was normalerweise nicht aktiv ist und wenn man dann noch im Kernel herum pfuscht.

 

[hoxi]

Eigentlich sollten Betreiber von Rechenzentren schon aus grundsätzlichen Sicherheitsüberlegungen die eingesetzte Hardware (wo es möglich ist, auch die Software) viel stärker diversifizieren. Die Netzwerkkomponenten, Server, Datenspeicher und dergleichen sollten sich deshalb in den Rechenzentren und deren Backup-Rechenzentren unterscheiden (hinsichtlich Hersteller und CPU-Architekturen), um bei Problemen möglichst kurzfristig auf die sicherere Seite wechseln zu können. Die bisher oft verwendeten Monokulturen bergen einfach viel zu große Gefahren und Abhängigkeiten.

 

[Grestorn]

Ich habe nur die polemischen Angriffe auf Intel von den AMD ...boys relativiert. Die Probleme sind branchenweit vorhanden, wenn auch momentan Intel ohne Zweifel mit deutlich weiter heruntergelassenen Hosen dasteht, würde ich nicht lachend auf deren nackten Hintern zeigen - am Ende steht man vielleicht genauso nackig da.

Also abwarten. Und vorallem nicht gleich mit Absicht und Verschwörung um sich schmeißen. Das sollte man besser amerikanischen Presidenten überlassen.

Und selbst da war man eigentlich nie verwunbar.

Der Exploit war nur anwendbar, wenn man etwas im Kompiler aktiviert, was normalerweise nicht aktiv ist und wenn man dann noch im Kernel herum pfuscht.

Bei solchen Relativierungen kann ich nur mit dem Kopf schütteln. Es geht doch gar nicht um konkrete Angriffe, sondern dass das Grundprinzip - nämlich dass spekulativ ausgeführte Codepfade nachweisbare Reste im CPU Zustand und Cache hinterlassen. Und das ist auf derzeit ALLEN Prozessoren so, die überhaupt spekulativ und/oder SMT ausführen können. Also eigentlich alle.

Das bei Intel als böse und Absicht hinzustellen, bei allen anderen aber zu relativieren - nur weil es momentan vielleicht keine guten Angriffe gibt - ist schon eine ziemlich einseitige Sicht.

 

[Cool Master]

Die bisher oft verwendeten Monokulturen bergen einfach viel zu große Gefahren und Abhängigkeiten.

Etwas anderes als eine Monokultur zahlt dir aber keiner.

 

[Wadenbeisser]

So schmilzt der IPC-Vorteil von Intel dahin. Bleibt nur noch der Takt...

Aber darum geht's hier auch gar nicht, sondern darum, dass Intel einfach kaum Informationen herausrückt. Für den Privatanwender vielleicht weniger kritisch, aber wie lange lassen sich das die Severhersteller/ -betreiber gefallen? Die müssen doch auch irgendwann mal die Schnauze voll haben?

Edit: @Exit666 unter mir:
Bei sowas "verbessern" SMT-Sicherheitslücken deine Online-Erfahrung noch
Kannst also getrost aktiviert lassen

Huch wie soll da was dahin schmelzen wenn sich die IPC doch ohnehin auf den Takt bezieht?

 

[Grestorn]

IPC = Instructions per Cycle.

Also die Performance einer CPU mit einem Kern und bei einem festen, vorgegebenen Takt. Und dabei spielt ganz besonders die Qualität des speculative execution und SMT eine Rolle.

 

[Hill Ridge]

Bei solchen Relativierungen kann ich nur mit dem Kopf schütteln.

Unterstell mir bitte nichts!

Es geht doch gar nicht um konkrete Angriffe, sondern dass das Grundprinzip - nämlich dass spekulativ ausgeführte Codepfade nachweisbare Reste im CPU Zustand und Cache hinterlassen.

kannst du das bei AMD nachweisen?
Nein?
Dann Mund halten!

Das bei Intel als böse und Absicht hinzustellen, bei allen anderen aber zu relativieren - nur weil es momentan vielleicht keine guten Angriffe gibt - ist schon eine ziemlich einseitige Sicht.

Nein, ich sehe es einfach aus der technischen Sicht!

Aus einem anderen Forum kopiert, ist gerade sehr passend.

Genau diese Diskussion ist das Ziel der Intel-Desinformationskampagne gewesen. Warum sonst sollten 2 völlig unterschiedliche Exploits den selben Namen bekommen mit Versionsnummern. Meltdown war schnell zu fixen, doch Spectre v1 ist übergreifend. Da nimmt man einfach verschiedene Sidechannel-Methoden und nummeriert sie durch, damit die Presse und Forenlandschaft nur noch über "Spectre" verkürzt diskutiert.

Verwundbar ist eine CPU wenn es einen PoC gibt. "Betroffen" ist kein Begriff aus der IT-Sicherheit, sondern ein Buzz-Word in diesem Kontext, das sich durchgesetzt hat.
Sobald man diese beiden Begriffe nämlich austauscht in dem Satz "AMD ist verwundbar/betroffen" endet auch die Diskussion und man ist sich einig und es gibt keine zwei Meinungen. Daher ist auch die Anerkennung eines Exploits mit einem PoC verbunden.
Kein PoC->Kein Exploit->Nicht verwundbar!
Betroffen? Ja, von der Berichterstattung und FUD.

wenn sich die IPC doch ohnehin auf den Takt bezieht?

Du verstehst nicht was IPC bedeutet!

 

[Grestorn]

@Hill Ridge:

Das muss nicht *ich* nachweisen, das ist bereits nachgewiesen. Bzw. wurde nie in Abrede gestellt, auch nicht von AMD.

Und Deinen Ton verbitte ich mir. Entweder vernünftig diskutieren oder bleiben lassen. Danke.

 

[Wadenbeisser]

Du verstehst nicht was IPC bedeutet!

Natürlich weiss ich das, das steht für "Instructions per Cycle" und jetzt rate mal wofür Cycle steht.

 

[Grestorn]

Eben. PRO Takt. Also wie schnell eine CPU bei einem gegebenen Takt ist.

Damit spielt nur noch die Ausführungsgeschwindigkeit, nicht aber Zahl der Kerne oder Taktrate eine Rolle. Und da ist Intel noch leicht im Vorteil, aber der schwindet eben wenn zunehmend Maßnahmen ergriffen werden müssen, die gerade die spekulative Ausführung und/oder SMT weniger effizient machen.

Deswegen ist die Aussage absolut korrekt, dass Intel hier dabei ist, einen Vorteil zu verlieren.

 

[Hill Ridge]

das ist bereits nachgewiesen.

Das entspricht nicht der Wahrheit!

Und Deinen Ton verbitte ich mir.

Mir egal!

Entweder vernünftig diskutieren oder bleiben lassen.

Warum diskutierst du dann nicht vernünftig?
Du stellst hier Behauptungen auf, die du nicht belegen kannst, da hat die Intel-PR wohl echt voll eingeschlagen:\

 

[Sun_set_1]

Ist das zeedys Zweitaccount oder bist du der Bruder von ihm?

 

[TrueAzrael]

Ich würde Intel schon faßt unterstellen, dies nicht versäumt sondern bewusst so implementiert zu haben, um die maximale Performance heraus zu holen.

Da Intel bei Spectre und Co. meines Wissens damit argumentiert hat, dass dies kein Bug sei sondern genau so dokumentiert ist, ist das anzunehmen und wäre auch nicht all zu verwerflich wenn man entsprechend darauf hin weist. Und nein der Hinweis in der x-seitigen Dokumentation welche die meisten Abnehmer außerdem wohl nie zu Gesicht bekommen reicht da mMn nicht.

Natürlich weiss ich das, das steht für "Instructions per Cycle" und jetzt rate mal wofür Cycle steht.

Ein Cycle ist aber taktunabhängig.
Instruktionen pro Zyklus, der Takt sagt dir dann wie viele Zyklen pro Sekunde der Prozessor schafft.

IPC * Takt = Instruktionen pro Sekunde

Die IPC selbst ist aber wie gesagt unabhängig vom Takt.

 

[Dai6oro]

Eben. PRO Takt. Also wie schnell eine CPU bei einem gegebenen Takt ist.

IPC ist unabhängig vom Takt. Und das nicht erst seit gestern.

Was du meinst ist Instructions per second der ist logischerweise taktabhängig.

 

[Wadenbeisser]

@Grestorn
Und damit sind auch die zusätzlichen virtuellen Kerne durch SMT raus welche ohnehin keine Zusatzleistung bringen sondern lediglich ungenutzte Rechenleistung für andere Prozesse nutzbar macht.
Bei der IPC selbst schmilzt mit der Deaktivierung vom SMT als garnichts und die Rechenleistung des Kerns wird nur über den Takt erhöht.

Ergänzung (24. August 2018)

Ein Cycle ist aber taktunabhängig.
Instruktionen pro Zyklus, der Takt sagt dir dann wie viele Zyklen pro Sekunde der Prozessor schafft.

IPC * Takt = Instruktionen pro Sekunde

Die IPC selbst ist aber wie gesagt unabhängig vom Takt.

Falsch

Die Maßeinheit Instructions per Cycle (IPC; deutsch Instruktionen pro Zyklus) bezeichnet die Anzahl der von einem Prozessor in einem Taktzyklus ausgeführten Befehle.

https://de.wikipedia.org/wiki/Instructions_per_Cycle

 

[werpu]

Selbst FALLS ein Intel-Ingenieur jemals auf die Idee gekommen sein sollte, dass es da ein Risiko gibt, dann mag er vielleicht ein ungutes Gefühl gehabt haben. Es ist aber WEIT davon entfernt, ein "Defeat-Device" zu sein, wie es VW in die Software eingebaut hat (Auswerten des Lenkereinschlags um den Prüfstand zu erkennen).

.

Hier der Beweis dass Intel hier bewusst Sicherheit geopfert hat:

https://www.reddit.com/r/programming/comments/7oaeel/openbsds_theo_de_raadt_warning_about_intel/

Da sind einige Links die bis 2007/2008 zurückgehen und die Core2 Reihe massiv kritisieren (ua. wegen ht und dem L1 cache)
Bisher ist Intel an einem VW Szenario noch vorbeigeschrammt, vmtl weil sie tief mit dem DOD im Bett liegen und von der US Regierung als wichtig eingestuft sind, wäre Intel ein dt. Konzern hätten wir schon seit Monaten einen 2. Fall VW.

 

[DarkInterceptor]

als intel und amd besitzer (zweitrechner der frau) würd ich aufgrund der vielen negativen meldungen (spectre usw) amd kaufen.
der leistungsverlust durch die patches spielt doch auch amd in die hände.
also wie ich das seh müsste intel erstmal das alles ausbügeln bevor ich wieder einen kaufen.

 

[TrueAzrael]

Falsch

https://de.wikipedia.org/wiki/Instructions_per_Cycle

Der Wikipedia-Artikel bestätigt doch was ich sage.

Merke: Taktzyklus ungleich Taktfrequenz

 

[HardRockDude]

Zitat News: "und macht einen schrecklichen Job" - das hätte man aber wirklich besser übersetzen können.

Ansonsten sieht es wohl nach einem grundlegenden Designproblem aus. Möglicherweise führt das früher oder später wohl zu einer neuen CPU-Architektur.

 

[calluna]

Ein Angriff über ein JavaScript beispielsweise, in der Breite, ohne exakte Daten über das Zielsystem, seine Hard- und SW-Konfiguration zu kennen, über einen Sidechannel-Angriff...

Interessant... wie genau funktioniert in JavaScript der Zugriff auf den Speicher? ;-)