Spectre und Meltdown
-
gfdgdgf schrieb:
Wird der Bug in den NextGen-CPUs von AMD und Intel gefixt sein?
Im Worst Case Fall dauert es 5 Jahre.
Also kannst du im Jahr 2023 wieder unbesorgt eine CPU kaufen:A fundamental flaw in the architecture will cost you five years and hundreds of millions of dollars.
https://danluu.com/hardware-unforgiving/
Im übrigen würde ich stark annehmen, das Intel das Problem schneller fixen wird können als AMD. Denn die haben wesentlich mehr Manpower, Fabriken und Labore.
Gut möglich, dass die parallel in Teams einen Fix entwickeln um wieder schnell eine fehlerfreie CPU auf dem Markt anbieten zu können.Letzteres könnten sie jetzt schon in etwa 10 Monaten erreichen.
Sie müssten nur die Pläne des alten Atom mit der In Order Execution herauskramen, davon einen Die-Shrink machen. Was wegen der Art und Weise, wie Lithografie funktioniert kein großes Problem sein dürfte und dann noch den Takt erhöhen, der durch den Die-Shrink und die niedrigeren Spannungen dann möglich sein dürfte.
Das einzige Problem dabei wäre, dass die meisten Extensions >= SSE4 dann fehlen dürften. Die gab es erst mit Silvermont und das ist ein Out-Of-Order Execution CPU. DDR4 Anbindung gäbe es auch nicht. Ebenso wäre die iGPU nicht auf der Höhe der Zeit (<= DirectX 9 Support). Aber durch den Die-Shrink wäre zumindest ein höherer Takt möglich, womit die CPU auch ansonsten schneller als die alten Atom sein dürften.
Intel hätte hier sogar noch mit Briarwood (Releasedatum Quartal 2 2013) eine Server CPU der Bonnel Architektur im Peto.AMD hat dagegen nichts auf die Schnelle anzubieten, die müssen ihre Out-Of-Order Execution Einheit reparieren, genau wie Intel auch bei deren größeren CPUs und das wird dauern. Vor allem hat AMD keine große Manpower und nicht so viele Teams wie Intel. Da sind sie also deutlich im Nachteil.
Das AMD weniger fixen muss, ist da nur ein kleiner Vorteil.
-
Die CPU hat keine "Fehler" in dem Sinn, ich würde das eher als Problem bezeichnen. Die Unterscheidung finde ich deswegen wichtig weil man "Fehler" typischerweise exakt festnageln und beheben kann. Hier ist das anders, bei der Menge an Optimierungen die alle das Timing von bestimmten Vorgängen ändern können, und alle nötig sind damit die CPUs ordentlich schnell sind, ist es kaum möglich irgendwann zu sagen "das ist jetzt 100% wasserdicht".
Im Worst Case wird es also ewig dauern.
-
computertrolls schrieb:
Sie müssten nur die Pläne des alten Atom mit der In Order Execution herauskramen, davon einen Die-Shrink machen. Was wegen der Art und Weise, wie Lithografie funktioniert kein großes Problem sein dürfte und dann noch den Takt erhöhen, der durch den Die-Shrink und die niedrigeren Spannungen dann möglich sein dürfte.
Das einzige Problem dabei wäre, dass die meisten Extensions >= SSE4 dann fehlen dürften. Die gab es erst mit Silvermont und das ist ein Out-Of-Order Execution CPU. DDR4 Anbindung gäbe es auch nicht. Ebenso wäre die iGPU nicht auf der Höhe der Zeit (<= DirectX 9 Support).Die von dir genannten Probleme sind IMO keine, das Zeug liesse sich ganz schnell integrieren wenn man es braucht.
Das echte Problem wäre dass du dann wieder ne CPU hast die lahm ist. Denn die Atome von damals waren auch verglichen mit CPUs mit identischem Takt lahm.
Und ich bin mir auch fast sicher dass man ähnliche Angriffe auch für Atom konstruieren kann. Vielleicht nur welche die lange nicht praktikabel sind, aber Timing-Unterschiede über die man an bestimmte "verbotene" Informationen kommen kann gibt es auch bei Atom CPUs.
-
hustbaer schrieb:
Die von dir genannten Probleme sind IMO keine, das Zeug liesse sich ganz schnell integrieren wenn man es braucht.
Ich weiß nicht wie lange es dauert, eine Extension einzubauen, aber bei nur < 10 Monaten hätte ich meine Zweifel dass das klappt.
Die fertigen von Skylake und Co sind, so schätze ich mal, sicher alle für deren out of Order Architektur gemacht und daher nicht 1:1 auf den alten Atom kopierbar.Das echte Problem wäre dass du dann wieder ne CPU hast die lahm ist. Denn die Atome von damals waren auch verglichen mit CPUs mit identischem Takt lahm.
Das echte Problem ist meiner Meinung nach die mangelnde Sicherheit.
Stell dir vor, du betreibst ein Rechenzentrum, das Webhostingdienste für viele verschiedene Firmen anbietet und die laufen alle in ihrer VM.
Spectre erlaubt, dass man aus den VM ausbrechen und die Informationen aller anderen Firmen einlesen kann.Für einen solchen Webserverdienstleister und die Firmen die darauf angewiesen sind, ist das schliechtweg ein Supergau.
Das gleiche Problem dürfte bei Banken und sonstigen kritischen Infrastrukturen bestehen.
Mit dem Design des alten Atom könnte man hier recht schnell eine sichere CPU auf den Markt werfen.
Und wenn ich so einen Shop hätte, dann würde ich mir sogar einen alten Bladeserver mit Briarwood CPUs (also vom alten Atom) auf dem Gebrauchtmarkt kaufen und meinen Shop damit betreiben.
Dass es dann unter Umständen etwas langsamer wird, das kann schon sein, aber das ist noch längst nicht so schlimm wie Kosten die durch ein Datenleck anfallen könnten.Die derzeit existierenden für Spectre anfälligen Out-of-Order CPUs sind einfach nicht mehr sicher und das ist IMO das wesentliche Problem.
Die paar Prozent Leistungsverlust sind nicht so schlimm, damit kann man durchaus leben, auch wenn es ein saurer Apfel ist, aber das ist noch einer den man essen kann. Eine unsichere CPU ist dagegen ein giftiger Apfel.Und ich bin mir auch fast sicher dass man ähnliche Angriffe auch für Atom konstruieren kann. Vielleicht nur welche die lange nicht praktikabel sind, aber Timing-Unterschiede über die man an bestimmte "verbotene" Informationen kommen kann gibt es auch bei Atom CPUs.
Spectre funktioniert nur bei Out Of Order CPUs.
Der alte Atom ist eine In Order CPU.
Hier gibt's eine sehr gute Erklärung, wenn jemand im Bekanntenkreis fragt, die ist auch für Laien geeignet.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
-
LOL, Jetzt wundert mich nichts mehr, warum die Presse "Lügenpresse" oder "Lückenpresse" genannt wird, so sieht Spectre und Meltdown bei der Presse aus:
https://pbs.twimg.com/media/DSxGaU_XcAAbVtx?format=jpg&name=small
-
so ist das eben bei den sog. weichen wissenschaften
-
Lieber computertrolls, es geht beim Verzicht auf OOE und Speculative Execution um wesentlich mehr als nur "ein paar Prozent"*. Was das Sprengen von VM-Grenzen angeht muss ich erst nochmal nachlesen - bin mir nicht sicher ob das überhaupt geht bzw. ein reales Problem ist welches nicht mit Software-Patches zu beheben ist. (Ich glaube nämlich dass es kein reales Problem ist, aber ich will hier nix behaupten wo ich mir nicht sicher bin.)
Davon abgesehen: Was Spectre ist und wie es funktioniert brauchst du mir nicht zu erklären bzw. irgend eine Teletubby-Erklärung verlinken - ich habe das sehr gut verstanden. Ich nehme an wesentlich besser als du.
Auch was "ähnliche Angriffe" bedeutet scheint dir nicht so ganz klar zu sein.
Diskussionen mit dir sind manchmal schon einigermassen anstrengend.
*: Hier, damit du nen Eindruck bekommst um was es da geht: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+S1260+%40+2.00GHz
-
hustbaer schrieb:
Lieber computertrolls, es geht beim Verzicht auf OOE und Speculative Execution um wesentlich mehr als nur "ein paar Prozent"*.
Bei den paar Prozent bezog ich mich auf die Meltdown und Spectre fixes für die Out-of-Order CPUs.
-
Bezüglich den Pentium G (Skylake) habe ich jetzt etwas weiter recherchiert und herausgefunden, dass sie die gleiche Signatur haben wie bspw. mein i7-6700K.
Damit teilen sie sich auch den gleichen Microcode.
-
Ist man sicher, wenn man nur vertrauenswürdige Websites ansurft und nur sichere Programme ausführt?
-
rtztz schrieb:
Ist man sicher, wenn man nur vertrauenswürdige Websites ansurft und nur sichere Programme ausführt?
Absolute Sicherheit gibt's nicht.
Aber es ist ein guter Ansatz.Ich empfehle noch die Verwendung von noScript als Browserplugin. Damit kann man sich das ein oder andere JavaScript Skript vom Leib halten und trotzdem eine funktionierende Webseite haben (wenn man die anderen JS Skripte, die dafür notwendig sind, erlaubt).
Dazu natürlich alles Patches für OS, Software und microcodes für die CPU einspielen, sofern verfügbar.
Mehr werde ich auch nicht tun können, mein i7 6700k ist noch viel zu neu, als das ich den jetzt ersetzen werde, außerdem wird es eh noch dauern, bis es wieder fehlerfreie CPUs gibt.Wer, was die beiden Sicherheitslücken betrifft, absolute Sicherheit haben will, der surft besser mit dem Raspberry Pi 3. Dessen CPU ist dafür nicht anfällig und ein Raspi ist günstig zu haben.
-
Mein Kubuntu 17.10 (Ubuntu 4.13.0-25.29-generic 4.13.13) auf einer Intel-CPU zeigt an:
dmesg | head -n1 [ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09Wann kommt also das Microcode-Update?
-
fdfdgg schrieb:
Mein Kubuntu 17.10 (Ubuntu 4.13.0-25.29-generic 4.13.13) auf einer Intel-CPU zeigt an:
dmesg | head -n1 [ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09Wann kommt also das Microcode-Update?
Für 0xba gibt's schon ein Update direkt von Intel, Ubuntu schläft da noch, ist bei mir auch so.
D.h. entweder selber einspielen, also von Intel downloaden oder auf Ubuntu warten bis die sich genehmigen.
-
rtztz schrieb:
Ist man sicher, wenn man nur vertrauenswürdige Websites ansurft und nur sichere Programme ausführt?
Noch eine kleine Anmerkung.
Der beste Kompromiss wäre wohl, wenn man auf dem raspberry Pi 3 surft und dessen Desktop dann via VNC auf dem x86 Rechner streamed.
Dann würde das ganze JS und Browsergedöns auf dem Raspi laufen und der ist gegen die genannten Sicherheitslücken immun.
Und für den Rest hätte man dennoch seine gewohnte x86 Umgebung.
-
fdfdgg schrieb:
Mein Kubuntu 17.10 (Ubuntu 4.13.0-25.29-generic 4.13.13) auf einer Intel-CPU zeigt an:
dmesg | head -n1 [ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09Wann kommt also das Microcode-Update?
Hier ein Auszug aus der releasenote Datei für die microcodes vom 8.1.2019:
Intel Processor Microcode Package for Linux 20180108 Release -- Updates upon 20171117 release -- IVT C0 (06-3e-04:ed) 428->42a SKL-U/Y D0 (06-4e-03:c0) ba->c2 BDW-U/Y E/F (06-3d-04:c0) 25->28 HSW-ULT Cx/Dx (06-45-01:72) 20->21 Crystalwell Cx (06-46-01:32) 17->18 BDW-H E/G (06-47-01:22) 17->1b HSX-EX E0 (06-3f-04:80) 0f->10 SKL-H/S R0 (06-5e-03:36) ba->c2 HSW Cx/Dx (06-3c-03:32) 22->23 HSX C0 (06-3f-02:6f) 3a->3b BDX-DE V0/V1 (06-56-02:10) 0f->14 BDX-DE V2 (06-56-03:10) 700000d->7000011 KBL-U/Y H0 (06-8e-09:c0) 62->80 KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80 KBL-H/S B0 (06-9e-09:2a) 5e->80 CFL U0 (06-9e-0a:22) 70->80 CFL B0 (06-9e-0b:02) 72->80 SKX H0 (06-55-04:b7) 2000035->200003c GLK B0 (06-7a-01:01) 1e->22Relevant wäre für uns beiden folgende Zeilen:
SKL-U/Y D0 (06-4e-03:c0) ba->c2
SKL-H/S R0 (06-5e-03:36) ba->c2ba ist die Versionsnummer des alten microcode. c2 wäre dann die neue.
SKL steht wahrscheinlich für Skylake.
U/Y für die Ultralowvoltage-Stromsparversionenn und H und S für die normalen CPUs, wobei S dann die Stromsparversion für die normalen Desktop CPUs wären.HSW dürfte Haswell sein.
KBL Kerby Lake
BDX Broadwell
IVT Ivy BridgeSKL, GLK, SKK usw. keine Ahnung. Eventuell die anfälligen Atoms oder Xeons.
-
Korrektur:
Ich meine natürlich 8.1.2018.
-
Liest man sich das hier durch:
Dann wird es wohl auf verschiedene Binärdistributionen der gleichen Linuxdistribution hinauslaufen.
Nehmen wir bspw. Debian.
Wir benötigen dann ein Debian mit Binärpaketen, die "return Trampolines" verwenden, für alle CPUs älter als Skylake.
Dann benötigen wir ein Debian mit Binärpaketen, die IBRS verwenden, für alle CPUs, die >= Skylake.Damit werden die Compilate für x86 CPUs sehr vielschichtig.
Und für die anderen Distributionen, außer Gentoo und Co, die sowieso alles selber compilieren, gilt natürlich das gleiche.
Aber gut, wenn der 32 Bit Zweig sowieso eingestellt wird, dann hält sich das vom Aufwand in Grenzen.Trotzdem es ist und bleibt einfach der pure Horror.
Und Spectre Variante 1 ist damit immer noch nicht gefixed.
-
Danke.
Wie hoch sind die Performance-Einbußen bei Linux und Intel? Auf Windows ja ziemlich hoch, vor allem bei SSDs: https://www.heise.de/newsticker/meldung/Intel-Benchmarks-zu-Meltdown-Spectre-Performance-sackt-um-bis-zu-10-Prozent-ab-SSD-I-O-deutlich-mehr-3938747.html
-
Es betrifft vor allem die Ein- und Ausgabe bei Datenträgern und alles was Kernelswitches erfordert.
Spiele sind davon kaum betroffen, da die in der Regel alles zuerst ins RAM Laden.
Inwiefern RPGs wie Skyrim, Fallout 4 usw. oder Spiele wie Minecraft und 7days to die betroffen sind, weiß ich nicht, aber diese Spiele zeichnet aus, das sie ständig Kartenmaterial von der Festplatte/SSD nachladen müssen. Leztere beiden benötigen auch Schreibzugriffe.Hier gibt's ein paar Benchmarks bezüglich Linux mit und ohne Patches gegen Spectre:
https://www.phoronix.com/scan.php?page=article&item=linux-retpoline-benchmarks&num=2
-
Bei GIMP gibt's einen größeren Performanceverlust:
https://www.phoronix.com/scan.php?page=article&item=pre-pcid-kptiretpoline&num=5
