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

[Knito]

Mein 8700K ist noch versiegelt. Mainboard hab ich erst die Tage gekauft.

Mein Drang, das System zusammenzubauen, hält sich grad irgendwie in Grenzen...

Bis Ryzen 2 halt ich's zur Not auch noch aus.

Würd ich an deiner Stelle sofort zurück schicken, die müssen jetzt tausende Rückabwicklungen durchführen. Und dann auf Ryzen 3 warten.

 

[der_Schmutzige]

Solange alles spekulativ ist (?) was die evlt. Leistungsverluste angeht, bleibt mir als Homeuser wohl nur, die sache mit Argusaugen zu verfolgen. Frohlocken bzw. Panikattacken vor dem Patch sind verschwendete Synapsenenergie.

Ich hoffe nur, dass es von Seiten der OS-Anbieter öffentlich deutlich gemacht wird, wann dieser Patch für ihr jeweiliges BS erfolgt und er nicht den Massen einfach und klammheimlich untergejubelt wird.

 

[Hallo32]

Ich hoffe nur, dass es von Seiten der OS-Anbieter öffentlich deutlich gemacht wird, wann dieser Patch für ihr jeweiliges BS erfolgt und er nicht den Massen einfach und klammheimlich untergejubelt wird.

Was erwartest du dir davon?

 

[UrlaubMitStalin]

Um welche Intel CPUs handelt es sich denn nun? Wirklich ALLE ?
Das glaube ich kaum... ein i486er hatte dieses feature wohl noch nicht. Bitte nachreichen um welche CPUs es sich handelt.

Ich finde es auch ein bisschen eigenartig, dass AMD-CPUs dadurch benachteiligt werden, obwohl sie alles richtig machen...
Wenn Intel CPUs plötzlich nur noch halb so schnell laufen, dann ist AMD über Nacht der unantastbare Performance-König

 

[der_Schmutzige]

Was erwartest du dir davon?

...persönliche Vergleiche zur Performance meiner Systeme anstellen zu können?
Das Ding still an irgendeinem Patchday mit rauszuhauen, ist einfach keine Art.

 

[I'm unknown]

Das Ding still an irgendeinem Patchday mit rauszuhauen, ist einfach keine Art.

Damit solltest du als Windows 10 User doch inzwischen sowieso gewöhnt sein?

Nur weil der Patch ausnahmsweise mal Leistung kostet ist das doch kein Grund für eine völlig neue Vorgehensweise. Noch dazu weil kaum jemand versteht um was es eigentlich geht, selbst hier im eher informierten Userkreis ist das durch diesen Thread ersichtlich.

 

[Trochaion]

Soweit ich das aktuell verstehe ist es ein Hardware-Bug, bei dem Intel keine Chance hat, das bei bestehenden Systemen selbst zu beheben. Warum das mit nem UEFI oder AGESA oder Microcode - Update nicht geht verstehe ich leider selbst nicht Und sind wir mal ehrlich, niemand außer AMD ist geholfen, wenn plötzlich alle Intel-CPUs an Leistung verlieren. Wieviel das im speziellen Fall auch immer sein mag.

Interessant ist trotzdem, dass der Bug ja scheinbar uralt ist und in über 10 Jahren noch niemandem aufgefallen ist. Darüber hinaus steht nichts auf golem, heise, bsi, pcgh, hwl...Tatsächlich etwas mysteriös.

Das ist korrekt. Im besten Fall kann das mit einem Stepping gefixt werden. Im schlimmsten Fall muss die Architektur geändert werden und man braucht eine neue CPU. Microcode behebt den Hardware-Bug, der hier vorliegt, AFAIK nicht.
UEFI schon gleich gar nicht, das betrifft nämlich nicht die CPU-Architektur an sich. Dass Microsoft gleich für alle Intel-CPUs pauschal die Leerung des Adresscaches einschalten will, lässt nicht auf eine schnelle Lösung hoffen.

 

[Intruder66]

Zum Thema ob Laufzeit- oder Kompilierparameter im Linux-Kernel hat sich Linus Torvalds, soweit ich verstehe, schon geäußert:

"The whole functionality is compile time controlled via a config switch and can be turned on/off on the command line as well"

https://git.kernel.org/pub/scm/linu.../?id=5aa90a84589282b87666f92b6c3c917c8080a9bf

 

[rob-]

Mir wären Untersuchungen lieber ob dies etwas mit der NSA zu tun hat.

 

[DKK007]

Interessant ist trotzdem, dass der Bug ja scheinbar uralt ist und in über 10 Jahren noch niemandem aufgefallen ist. Darüber hinaus steht nichts auf golem, heise, bsi, pcgh, hwl...Tatsächlich etwas mysteriös.

PCGH hat mittlerweile berichtet, nur dass dort die technischen Hintergründe fehlen:
http://www.pcgameshardware.de/CPU-H...rneut-Hinweise-auf-Sicherheitsluecke-1247001/

 

[Steffen]

Um welche Intel CPUs handelt es sich denn nun? Wirklich ALLE ?

Wie ich weiter oben nun wirklich mehrfach geschrieben habe, aktiviert Linux diesen Workaround auf sämtlichen Intel-CPUs, weshalb die Vermutung naheliegt, dass auch wirklich alle noch irgendwie relevanten Intel-CPUs betroffen sind. Ja, vielleicht ist dein 286er safe, herzlichen Glückwunsch.

PCGH hat mittlerweile berichtet, nur dass dort die technischen Hintergründe fehlen:
http://www.pcgameshardware.de/CPU-H...rneut-Hinweise-auf-Sicherheitsluecke-1247001/

Das liest sich so als hätte PCGH bei uns abgeschrieben ohne die Quelle zu nennen. Saftladen.

Mittlerweile steht die Sache übrigens auch bei The Register: 'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign (dort mit technischen Details)

Ich habe übrigens mal auf meinem Notebook mit Intel Core i7-4600U (3½ Jahre alt) Linux 4.15-rc6 mit Page-Table Isolation kompiliert. Standardmäßig war PTI dann aktiviert (Boot-Log "Kernel/User page tables isolation: enabled"), mit dem Kernel-Parameter "pti=off" konnte ich es abschalten (Boot-Log "Kernel/User page tables isolation: disabled on command line"). Mit der Phoronix Test Suite habe ich dann ein paar einfache Benchmarks ausgeführt. Ich konnte aber in keinem auf Anhieb lauffähigen Benchmark Abweichungen außerhalb der Messungenauigkeit festellen (getestet habe ich pts/blake2, pts/build-linux-kernel, pts/openssl, pts/phpbench, pts/pybench und pts/sqlite).

Ich glaube eigentlich nicht, das ich irgendwas falsch gemacht haben könnte (das Boot-Log sagt ja eindeutig ob PTI aktiviert ist oder nicht) aber dass meine Messungen wirklich gar keinen Unterschied zeigen macht mich dann schon stutzig. Irgendwo müssen die von den Linux-Entwicklern genannten 5% ja herkommen. Vielleicht müsste man Netzwerk- oder IO-Benchmarks nutzen, weil die mehr Syscalls erzeugen? Ich hätte gedacht, dass man einen kleinen Unterschied auch bei anderen Benchmarks sehen sollte.

 

[DKK007]

Hängt auch davon ab, wie stark ein Programm bisher vom TLB profitiert hat. Also wie oft Adressen wiederverwendet wurden, z.B. in einer Schleife.

 

[der_Schmutzige]

Damit solltest du als Windows 10 User doch inzwischen sowieso gewöhnt sein?

Nur weil der Patch ausnahmsweise mal Leistung kostet ist das doch kein Grund für eine völlig neue Vorgehensweise.

Jap, eigentlich haste recht, so läufts ja wirklich in der Windows-Welt. Wie viele Win-User lesen am Patchday in den Notes?
Und warum soll i.d.F. MS schlechte Publicity für unpopuläre Performanceeinschnitte dank Intels Hardwareproblem einheimsen?
Naja, bleib ich eben nebenbei dran...

 

[Hallo32]

...persönliche Vergleiche zur Performance meiner Systeme anstellen zu können?
Das Ding still an irgendeinem Patchday mit rauszuhauen, ist einfach keine Art.

Persönlich sehe ich es gemischt.
Für Performance Vergleiche dürfte es interessant sein den Patch einzeln zu bekommen.
Kritisch sehe ich es in denn Fall, wenn Leute diesen Patch dann blocken weil nun die Anwendung ein wenig langsamer läuft und es somit wieder viele Installationen mit bekannten Sicherheitslücken gibt.

 

[Wadenbeisser]

Da die aktuellen Modelle letztendlich Abkömmlinge der Core Architektur sind gehe ich davon aus das der Fehler in erster Linie auf diese Architektur Familie betrifft aber das hilft einem nicht wirklich weiter.

 

[DKK007]

Ist die Frage, wie Intel reagiert. Das einfachste wäre wohl, alle betroffenen Intel-CPUs gegen Ryzen 2000 zu ersetzen.

 

[I'm unknown]

Das einfachste wäre wohl, alle betroffenen Intel-CPUs gegen Ryzen 2000 zu ersetzen.

Ist das ernst gemeint oder ein Trollversuch?

Falls ersteres: Dir ist klar, was das für Auswirkungen hätte (die finanziellen mal gar nicht mit berücksichtigt)?

 

[DKK007]

Bisher hat sich Intel noch nicht geäußert, was die machen wollen.

 

[Hallo32]

@Steffen

"du -s" Wurde irgendwo als negativ Bsp genannt.

 

[Jolly91]

Sagt bloß ihr hättet nicht gedacht das sowas möglich sein könnte?

Das hat man vor Jahren schonmal spekuliert, jetzt ist es wahr. Wie überraschend...