Crosstalk-Sicherheitslücke: Seitenkanalattacke über Kerne hinweg ebenfalls möglich

[HWL News Bot]

Die ursprünglichen Spectre- und Meltdown-Sicherheitslücken waren nur der Anfang einer Reihe ähnlicher Lücken und daraus resultierender Attacken und es war klar, dass Intel dieses Thema noch über Jahre begleiten würde. In einem kleineren Rahmen war auch AMD zumindest von Spectre betroffen.
... weiterlesen

 

[Shevchen]

Andere, wie RDMSR, lässt man hingegen offen auf dem Staging Buffer arbeiten, da man einen zu großen Einfluss der Leistung befürchtet.

Ähm... gehts beim Thema Fehlerbehebung nicht darum, den Fehler zu beheben und *dann* zu gucken, wie man es so optimiert, dass der Einfluss so gering wie möglich ist?

Wenn da jetzt Bereiche sind, die weiterhin offen sind, kann man sich doch den ganzen Patch sparen, oder?

Phoronix hat bei bestimmten Benches mehr als 50% Leistungsverlust gemessen. Das tut zwar weh, aber es deswegen nix zu fixen verballhornt die gesamte Sicherheitsdebatte.

 

[FirstAid]

Bei den vielen Sicherheitslücken, frage ich mich ernsthaft, ob der kleine Speicher der Intel CPUs noch ausreicht, um künftige Sicherheitslücken zu stopfen!

 

[sch4kal]

Ähm... gehts beim Thema Fehlerbehebung nicht darum, den Fehler zu beheben und *dann* zu gucken, wie man es so optimiert, dass der Einfluss so gering wie möglich ist?

Wenn da jetzt Bereiche sind, die weiterhin offen sind, kann man sich doch den ganzen Patch sparen, oder?

Phoronix hat bei bestimmten Benches mehr als 50% Leistungsverlust gemessen. Das tut zwar weh, aber es deswegen nix zu fixen verballhornt die gesamte Sicherheitsdebatte.

Ohne jetzt genauer zu wissen, welche Befehle noch von dem µCode-Patch ausgeschlossen sind:
- Liest RDMSR "nur" ein Register aus
- Ist RDMSR nur im priviliged Modus, also mit root Rechten ausführbar.

B2T: Natürlich ärgerlich für Intel, RDRAND wird von vielen Programmen benutzt, obgleich man für wirklich sensible, kryptografische Operationen sich sowieso nicht auf einen TRNG eines x86-Prozessors verlassen sollte, das macht man besser mit dedizierter Cryptohardware in Form von Smartcards etc.
Was mich jedoch noch interessieren würde, sind Icelake CPUs bzw. die Sunnycove µArch auch betroffen ? Da Cascade-Lake wohl nicht betroffen ist.

 

[Fimbulvetr]

Hab versucht, die Liste der betroffenen Prozessorfamilien von Intel zusammenzufassen:

Haswell: betroffen
Haswell-E: nicht
Broadwell: betroffen
Broadwell-E: nicht
Skylake: betroffen
Kaby Lake: betroffen
Coffee Lake: betroffen
Whiskey Lake: betroffen
Comet Lake: nicht
Ice Lake: nicht

Skylake-SP: nicht
Skylake-X: wahrscheinlich wie SP, nicht
Kaby Lake-SP: ? (wahrscheinlich nicht)
Kaby Laby-X: ? (ebenso)
Cascade Lake-SP: nicht
Cascade Lake-X: wahrscheinlich wie SP, nicht

Atom (Silvermont, Airmont, Goldmont, Tremont): nicht
Xeon Phi (Knights Landing, Knights Mill): nicht

War Iny Bridge noch nicht betroffen, oder ist diese Generation blos zu alt, um noch irgendwen zu interessieren?

 

[lablaka]

Ähm... gehts beim Thema Fehlerbehebung nicht darum, den Fehler zu beheben und *dann* zu gucken, wie man es so optimiert, dass der Einfluss so gering wie möglich ist?

Wenn da jetzt Bereiche sind, die weiterhin offen sind, kann man sich doch den ganzen Patch sparen, oder?

Phoronix hat bei bestimmten Benches mehr als 50% Leistungsverlust gemessen. Das tut zwar weh, aber es deswegen nix zu fixen verballhornt die gesamte Sicherheitsdebatte.

Das Konzept der spekulativen Ausführung an sich ist unsicher, so wie viele andere Architekturtweaks auch. Wenn es rein nach Sicherheit gehen würde, hätten wir heute noch so langsame CPUs, da sind die 50% Worst Case von Phoronix gar nichts gegen.

Die ganzen CPU-Sicherheitslücken der letzten Jahre sind überbewertet. Da gab es hunderte Seiten lange Threads in Hardware-Foren, bei denen sich Nutzer aufregen, die schon aufgrund der Art eines möglichen Exploits niemals betroffen sein werden und durch etwaige Fixes in ihrem Anwendungsbereich eine geringe einstellige Prozentzahl an Leistungseinbußen sehen.

Relevant sind die Lücken bisher vor allem für die Anbieter von Cloud-Computing, weil du dort Code anderer Nutzer auf der selben Hardware laufen hast und die Virtualisierung keinen vollständigen Schutz bietet.

Als normale Privatperson kannst du das auf deinem Home-Rechner alles schön ignorieren und (so weit noch per Flag möglich) deaktivieren.

 

[cunhell]

Das Konzept der spekulativen Ausführung an sich ist unsicher, so wie viele andere Architekturtweaks auch. Wenn es rein nach Sicherheit gehen würde, hätten wir heute noch so langsame CPUs, da sind die 50% Worst Case von Phoronix gar nichts gegen.

Komischer Weise, sind Stand jetzt, andere Prozessorhersteller deutlich weniger von solchen Sicherheitslücken betroffen. Man scheint also bei entsprechenden Vorsichtsmaßnahmen, die Problematik deutlich reduzieren zu können. Und diese Prozessoren sind nicht mehr als 50% langsamer als die Intel-Prozessoren. Von Deinen massiven Performanceeinbußen gar nicht zu sprechen.

Die ganzen CPU-Sicherheitslücken der letzten Jahre sind überbewertet. Da gab es hunderte Seiten lange Threads in Hardware-Foren, bei denen sich Nutzer aufregen, die schon aufgrund der Art eines möglichen Exploits niemals betroffen sein werden und durch etwaige Fixes in ihrem Anwendungsbereich eine geringe einstellige Prozentzahl an Leistungseinbußen sehen.

Nur weil es für alle Lücken noch keine bekannten Möglichkeiten gibt, diese einfach auszunutzen, heisst das nicht, dass es nicht geht. Manche der Expoits konnte man sogar sehr einfach ausnutzen, wenn die Lücken nicht geschlossen werden. Und nicht alle Rechner mit diesen CPUs laufen unter Windows. Bei Linux-Systemen kann man sehr wohl mehrere User gleichzeitig auf einer Kiste haben. Und wenn ich dann ein Programm oder Script habe, dass im Userkontext läuft aber die Lücke ausnutzen kann, kann das schon ein Problem sein. Diese Prozessoren werden nämlich nicht nur im privaten Umfeld eingesetzt.
Und manche Lücken konnten sogar durch Browser-Scripts ausgenutzt werden.

Relevant sind die Lücken bisher vor allem für die Anbieter von Cloud-Computing, weil du dort Code anderer Nutzer auf der selben Hardware laufen hast und die Virtualisierung keinen vollständigen Schutz bietet.

Und diese Tatsache macht das Ganze dann besser? Wenn ich als Cloudbetreiber plötzlich HT abschalten muss und 20% -30% Leistung verliere, habe ich ein massives Problem. Ganz zu schweigen sind die Kunden sicher nicht begeistert, wenn die eigene VM durch eine nicht gefixte Lücke kompromitiert wurde.

Als normale Privatperson kannst du das auf deinem Home-Rechner alles schön ignorieren und (so weit noch per Flag möglich) deaktivieren.

Genau, und sich dann wundern warum plötzliche Accounts gehackt oder ähnliches passiert und Du keine Ahnung hast, warum. Offen gesagt, spielt eine solche Einstellung Ganoven schön in die Hände.

Cunhell