News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

MrJules schrieb:
Sie wurde ja nicht damit beworben, dass sie Operation A in Zeit X ausführen kann.


Der Autovergleich zieht hier nicht, da ein bestimmter PS-Wert bzw. Hubraum einer bestimmten Kraft entspricht, die unter allen Fahrzeugen vergleichbar ist. GHz hingegen entsprechen (die CPU wird nicht mit IPC beworben) je nach IPC einer unterschiedlichen Rechengeschwindigkeit und sind nicht allgemein vergleichbar im Hinblick auf die Leistung.

Vor allem in Deutschland: Null Chance. :D In den USA werden es bestimmt welche probieren, aber ich sehe auch da keine großen Erfolgsaussichten.

Ich warte ab was der Verbraucher Schutz zu den Thema sagt. Die haben auch Microsoft damals in die Knie gezwungen. Und der Autovergleich hingt nicht. Da bei jeden Vergleichstest genau das zum Vergleich gegen gesetzt wird. Leider hat die CDU Sammelklagen in der BRD verhindert sonst hätte man jetzt ein ganz einfaches Mittel einen Schadensersatz zu bekommen. Da ich nur Intel CPU Hardware habe, werde ich abwarten ob oder was der Deutsche Verbraucherschutz in der Sache macht. Wenn Leute erfolgreich Klagen werde ich das auch machen.
 
Zuletzt bearbeitet:
kisser schrieb:
Ist doch eher ein Indiz dafür, dass das ganze deutlich überdramatisiert wird, oder nicht?

es wird sich noch zeigen welche geheimdienste davon evt schon jahre gebauch machen ich lasse ungern 10 jahre meine wohnungtür unverschlossen wird schon keiner merken
 
Trochaion schrieb:
Prinzipiell wäre es eleganter, nur das eine Update auslassen zu können oder direkt einen Switch in den Kerneloptionen anzubieten. Updates generell sperren ist tatsächlich keine gute Idee.

Da gebe ich dir recht. Daher spiele ich die Updates halb bis vierteljährlich manuell ein. Denn der mir immer noch zu schnelle Slow Ring und die Bevormundung seitens Microsoft haben mich dazu gezwungen solche Maßnahmen zu ergreifen... Ich Update quasi was ICH updaten möchte.
 
Mir ist nicht klar wieso für die Funktion nicht einfach die CPU-ID abgefragt wird.
Mit der CPU-ID kann man also schon abfragen, ob die aktuell vorliegende CPU von dem Problem betroffen ist, da nicht nur der Hersteller, sondern auch die Features sowie CPU-Reihe abgefragt werden können.

Drumherum fehlt nur eine Selektionsmöglichkeit mit der der Besitzer diesen automatischen Failsafe umgehen kann. Ob das eine gute Idee ist, ist momentan allerdings überaus fragwürdig.
So wie das Thema auf breiter Front (Windows, Linux-Kernel, MacOS,...) gerade gefixed wird, ist wohl Gefahr in Verzug und ich sehe nicht, wieso das nicht auch im privatem Umfeld eine Rolle spielen sollte (Viren/Trojaner könnten hier weitere Angriffspunkte durch einen Hardware-Fehler der CPU erhalten).
 
Am Ende des Tages ist jeder von Servern und Rechenleistung irgendwo abhängig.

Und wenn es so wäre, wäre es ungeheuerlich, das ein Bug in allen Intel Cpus der letzten 10 Jahre die Welt lahmlegen könnte, also bei aller liebe, aber irgendwann ist hier auch Schluss mit der Märchenstunde.


Leute was schreibt ihr hier?

Genau diese Angst mache, deine Daten landen dann im Darknet und ein krimineller nutzt die für einen Onlineshop in deinem Namen mit gefälschten Markenartikeln,

würde garnicht gehen, weil den seine Server ja auch dann nicht mehr funktionieren wenn durch den Bug die Welt untergeht,

ausserdem gabs das alles schon vorher, da brauchte nur ein Anwalt zum Provider, der gab die Daten raus und schwups hattest du eine Rechnung von einem Inkasso Büro wegen Urheberrechtsverletzung.
 
Kleiner Exkurs: Prozesse arbeiten mit virtuellen Speicheradressen („Virtual Memory“) beginnend bei 0. Es ist die Aufgabe des Kernels, eine freie Stelle im RAM (oder im Swap bzw. der Auslagerungsdatei) zu finden und diese virtuellen Adressen zur Laufzeit des Prozesses in physische Adressen zu übersetzen.

Muss ich mir das wie Array-Aufrufe in C/C++ vorstellen? Da rufe ich als Coder ja auch das Element mit der "Adresse" x im Array auf und der Kernel oder wer auch immer übersetzt das dann in die richtige Speicheradresse. Ist das ungefähr die gleiche Idee?
 
knoxxi schrieb:
Wir brauchen 14 neue 2HE Server, ich denke dieses mal könnte der dicke Epyc den Zuschlag bekommen.

Aber nur wenn euer präferierter Hersteller entsprechende Systeme bietet. Also Dell und HPE.
Von Fujitsu gibt es immer noch nichts mit AMD inside (=weiterhin Intel-only Server). Das ist zumindest mein Stand von vor 3 Monaten.
Dann gibt es noch von anderen zusammengebaute Systeme mit Tyan und Supermicro Boards.

Kurz davon gab es ja auch noch die VMware ESXi vSphere Probleme mit dem Pink Screen of Death bei Ryzen/Epyc (ist mittlerweile gefixed).
AMD hat leider noch einen weiten Weg vor sich.
Naja nächste Woche wird es auf der CES noch mal spannend...Ryzen2 steht vor der Tür (wohl ab März 2018).
 
Lord Wotan schrieb:
30% Leistungseinbruch, wird hier gesagt. Das heißt ja übersetzt eine 30% schlechtere CPU als man in PC hat. Oder? Also was sagt das Deutsche Verbraucher Recht dazu? Das man wegen eines Hardwarebugs einen 30% Leistungseinbruch hat. Beim Auto wäre da garantiert ein Schadensersatz fällig. Wenn dir das egal ist OK. Mir ist das nicht egal.

Ist das so eine Art Chewbacca-Verteidung? Anstatt irgendwas belangloses zu erzählen kannst Du doch auch einfach mal allgemeingültige Benches vorlegen, in denen ein 4790K mit dem Patch in jedem Szenario um 30% weniger Leistung bringt. Aber durchweg in jedem Szeanrio, denn erst dann kann man von Deinen 30% Realverlust sprechen.

Bis nicht geklärt ist, in welchem Szenario welcher Prozessor wieviel Leistung verliert würde ich einfach ganz stumpf die Geschichte aussitzen, Punkt.
 
Zuletzt bearbeitet:
Piep00 schrieb:
Brian Krzanich (seines Zeichens Intel-CEO) scheint sich gerade im großen Stil von seinen Aktien getrennt zu haben. [...] Ich lese gerade, dass einige Medien den Verkauf jetzt direkt mit der Sicherheitslücke in Verbindung bringen, obwohl dieser wohl schon am 19.12.2017 realisiert wurde. [...]

Na ja, Intel hat ja derzeit auch andere Problemzonen. Erst neulich wurde hier daran erinnert, dass der 10-Nanometer-Start immer noch nicht in Sicht ist. Niemand weiß, ob es vielleicht in der Fab 28 so zugeht, wie am Schönefelder BER. :eek:
 
Flomek schrieb:
Ist das so eine Art Chewbacca-Verteidung? Anstatt irgendwas belangloses zu erzählen kannst Du doch auch einfach mal allgemeingültige Benches vorlegen, in denen ein 4790K mit dem Patch in jedem Szenario um 30% weniger Leistung bringt. .
Die Seite hier hat das Behauptet. Also frage Computerbase oder Hardwareluxx. Die haben das gemessen und von jeder CPU geredet. Ein Hardwarebug ist jedenfalls nach Deutschen Verbraucher Recht ein Anspruch auf Ausgleich. Da der Bug schon bei der Herstellung bestand. Und wenn das Patch Leistung kostet, ist das eine Sachminderung. Mir ist das nicht egal. Ich habe 2 PC, ein Laptop , das Surface Tablett und einen HTPC. Alle mit Intel CPU.
 
Zuletzt bearbeitet:
xmarsx schrieb:
Aber nur wenn euer präferierter Hersteller entsprechende Systeme bietet. Also Dell und HPE.
Von Fujitsu gibt es immer noch nichts mit AMD inside (=weiterhin Intel-only Server). Das ist zumindest mein Stand von vor 3 Monaten.
Dann gibt es noch von anderen zusammengebaute Systeme mit Tyan und Supermicro Boards.

Kurz davon gab es ja auch noch die VMware ESXi vSphere Probleme mit dem Pink Screen of Death bei Ryzen/Epyc (ist mittlerweile gefixed).
AMD hat leider noch einen weiten Weg vor sich.
Naja nächste Woche wird es auf der CES noch mal spannend...Ryzen2 steht vor der Tür (wohl ab März 2018).

Nö wir sind nicht mit den großen Herstellern verheiratet. Wir kaufen auch bei kleinen.
Die IT äußert wünsche und ich kümmere mich um die kaufmännische Abwicklung. Auf den Servern läuft eigene Software.
 
ZU Frage Schadensersatz, hier wird eher softwareseitig ein Fehler in der Architektur (also auch der Hardware) ausgebessert. Ähnlich wie die neue Steuersoftware bei VW wegen der Abgaswerte. Und in der Frage stehen Urteile an. Ob das einen Schadensersatz auslöst. Also müsste man das auf Intel übertragen können und Schadensersatz einfordern dürfen. In den USA ist das wahrscheinlich aber einfacher.
 
Lord Wotan schrieb:
Die Seite hier hat das Behauptet. Also frage Computerbase oder Hardwareluxx. Die haben das gemessen und von jeder CPU geredet.
Du verstehst es echt nicht und verbreitest weiterhin Fehlinformationen? Es ist von bis zu 30% Leistungseinbußen im Worst Case die Rede. Nicht jede Intel Generation und nicht jeder Anwendungsfall ist aber gleich schwer betroffen (auch wenn das Sicherheitsproblem überall besteht)! Das bedeutet also eben nicht, dass jede Intel CPU nach dem Patch 30% langsamer läuft...

Und deine großen Reden bzgl. Schadensersatz kauft dir auch niemand ab. Lies dich lieber was in die Thematik ein und halt den Ball was flacher.
 
Zuletzt bearbeitet:
Zorkarak schrieb:
Muss ich mir das wie Array-Aufrufe in C/C++ vorstellen? Da rufe ich als Coder ja auch das Element mit der "Adresse" x im Array auf und der Kernel oder wer auch immer übersetzt das dann in die richtige Speicheradresse. Ist das ungefähr die gleiche Idee?

Jein :)

Physische Adresse

Du kannst Dir einen DDR Aufbau und seine Adressen wirklich wie Schiffe versenken vorstellen. Feld A1, B3 usw usf., natürlich nur viel größer. Was irgendwann in 00000x1 resultiert.

Nun kommen Sicherheitstechniken wie ASLR zum Einsatz, welche den Speicherbereich und seine Adressen durcheinandewürfeln, randomisieren.

Ein Programm mag sowas aber natürlich gar nicht bzw. muss es ja seine Speicherbereiche kennen. Würde man dem Programm nun die neuen Adressbereiche mitteilen, würde das Sicherheitskonzept nicht mehr greifen.

Virtuelle Adressen

Also kommen virtuelle und physische Adressen ins Spiel. Die virtuelle bleibt gleich, während hingegen die physische ständig randomisiert und verschoben werden kann. Das Mapping der beiden Bereiche übernimmt dann der Kernel.
Soweit so gut, mit dem Intel-Bug kann ich nun direkt auf physische Adressbereiche schreiben.

Wieso ist das Ganze so wichtig?

Zum Beispiel relevante Systemprozesse (privilegierte Prozesse die eigentlich alles dürfen) laden oder legen Daten standardmäßig aus/in einen bestimmten Speicherbereich bspw. 0000x1. Nun legt der Prozess dort Daten ab. Der Kernel geht hin, randomisiert diese physisch und übernimmt etwa ala 0000x1[v]= 0000x2[p].

Von außen könnte ich nun zwar physisch 0000x1 attackieren und versuchen dort Daten abzulegen, weil ich weiß das Systemprozesse XY diese früher oder später abrufen wird. Bringt aber durch ASLR nichts mehr, da die Daten nun physisch auf 0000x2 liegen. Ich müsste also Rätselraten spielen.

Was hat nun der IntelBug damit zu tun?

Durch den Fehler können (vermutlich /theoretisch ) bereits vor Randomisierung die Daten getauscht werden. Systemprozess legt die Daten ab. Ich attackiere und tausche diese Daten mit infiziertem Code aus, da der TLB (wie genau auch immer) mich wohl noch auf 0000x1 zugreifen lässt. Ich tausche die Daten also mit Schadcode, welcher anschließend früher oder später von einem privilegiertem Systemprozess ausgeführt wird.

That’s it, take over done.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Lord Wotan schrieb:
Die Seiten verbreiten das...

Dann sollte einer von uns beiden stark an seiner Lesekompetenz arbeiten. Aber zur Untermauerung Deiner These kannst Du den Teil doch bestimmt aus der News zitieren, oder?
 
Wer lesen kann ist klar in Vorteil. Lesen ist nicht eures oder? Lese die Berichte auf den drei Seiten, der jeweiligen Betreiber und gut ist. Ich bin doch nicht dein google. Es steht Geschrieben 1. jede Intel CPU ist betroffen und 2. bis zu 30% Leistungseinbruch gemessen unter Linux. So nun ihr. Wäre trotzdem nett wenn ihr Sachlich bleibt.
 
Zuletzt bearbeitet:
Hallo,
ich habe eine Verständnisfrage.

Diese Lücke kann also behoben werden, aber was ich noch nicht verstehe ist, geschieht dies durch ein normales Update das jeden zweiten Dienstag im Monat ausgerollt wird, oder durch eines dieser großen Upgrades?

Danke.
MfG
 
Zurück
Oben