Spectre und Meltdown
-
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
-
computertrolls schrieb:
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.
Dann musst du dich klarer ausdrücke. Ich kann das da
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.nämlich wirklich nicht rauslesen. Im Gegenteil, da war für mich sogar sehr klar dass du etwas meinst was nicht "derzeit existierende für Spectre anfällige Out-of-Order CPUs" sind, und das sind nunmal nur CPUs ohne OOE.
Ich glaube aber dass die ganze Sache ausreichend gut mit der nächsten oder übernächsten CPU Generation gelöst sein wird, und das vermutlich auch ohne grosse Performance-Einbussen. Wobei ich mit "ausreichend gut" meine dass real mögliche Angriffe unpraktikabel sind (zu langsam und/oder zu ungenau), und mit einer CPU Generation einen Intel Tick oder Tock Schritt (also nicht eine neue Microarchitektur). Klar, ist nur ne Schätzung/Bauchgefühl, aber wir werdens ja sehen.
-
hustbaer schrieb:
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.)
OK, gut hier hatte ich Unrecht, bzw. meine Vermutung war falsch. VMware ESXi und vermutlich auch andere "full virtualization" Hypervisor werden zwar aktuell als immun gegen Meltdown angesehen, aber nicht immun gegen Spectre.
-
hustbaer schrieb:
computertrolls schrieb:
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.
Dann musst du dich klarer ausdrücke. Ich kann das da
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.nämlich wirklich nicht rauslesen. Im Gegenteil, da war für mich sogar sehr klar dass du etwas meinst was nicht "derzeit existierende für Spectre anfällige Out-of-Order CPUs" sind, und das sind nunmal nur CPUs ohne OOE.
Das war klar erkennbar, sowohl aus dem Satz, als auch aus dem Kontext.
Der saure Apfel bezieht sich nämlich auf den Performanceverlust, währen der giftige Apfel die nicht reparierbare Sicherheitslücke beschreibt.
Hätte ich von den Atoms gesprochen, dann hätte ich sie explizit genannt.
Dass ich den Atom nicht meinen kann, hättest du daran erkennen können, dass eine High-End Skylake oder gar ein Coffee-Lake CPU deutlich schneller ist, als so ein alter Atom und man hier nicht von ein Bisschen Performanceverlust sprechen kann.Ich glaube aber dass die ganze Sache ausreichend gut mit der nächsten oder übernächsten CPU Generation gelöst sein wird, und das vermutlich auch ohne grosse Performance-Einbussen.
Hoffen wir es mal.
Ich befürchte, dass ein voller Schutz länger dauert und man in der kürzeren Zeit nur ein paar kleine Fixes machen wird können.Wobei ich mit "ausreichend gut" meine dass real mögliche Angriffe unpraktikabel sind (zu langsam und/oder zu ungenau), und mit einer CPU Generation einen Intel Tick oder Tock Schritt (also nicht eine neue Microarchitektur). Klar, ist nur ne Schätzung/Bauchgefühl, aber wir werdens ja sehen.
Zu langsam würde mir nicht reichen.
Den Serverbetreibern noch weniger.
Da stehen Server ja teils Monate rum, manche mit einer VM worauf etwas läuft, bei denen sich die Admins in zig Monaten nicht drum kümmern.
Vor allem wenn die VM von Laien gemietet wurden.
Deren Horror, also der der Hostbetreiber, möchte ich jetzt nicht haben.
-
AMD ist jetzt auch von Spectre 2 betroffen (bisher war es nur Spectre Variante 1):
-
Eigentlich könnten wir auch mal über Verschwörungstheorien reden. <Aluhut aufsetz>
Was meint ihr, wusste der russische Geheimdienst schon seit vielen Jahren davon?
Und wenn ja, hat er mit diesen Lücken die Wahlcomputer in den USA manipuliert, gesetzt den Fall, es waren für Spectre oder Meltdown anfällige CPUs verbaut?Ich meine, früher, während dem kalten Krieg hat man in der DDR ja auch den 8086 CPU ganz genau unter die Lupe genommen und kopiert, da wäre es doch naheliegend, dass man sich als Geheimdienst in Russland auch den Microcode der aktuellen CPUs ganz genau ansieht und die CPUs auf Schwachstellen untersucht.
-
computertrolls schrieb:
Was meint ihr, wusste der russische Geheimdienst schon seit vielen Jahren davon?
möglich, wer weiß...
computertrolls schrieb:
Und wenn ja, hat er mit diesen Lücken die Wahlcomputer in den USA manipuliert, gesetzt den Fall, es waren für Spectre oder Meltdown anfällige CPUs verbaut?
Spectre noch Meltdown erlauben lediglich das Ausspionieren aber nicht das Manipulieren von Daten...
-
dot schrieb:
Spectre noch Meltdown erlauben lediglich das Ausspionieren aber nicht das Manipulieren von Daten...
Die Idee ist doch, das Adminpasswort auszulesen, Sprungadressen zu finden, oder ähnliches. Und damit dann Rechte zu eskalieren, bis man volle Kontrolle, auch über die Daten, hat.
Trotzdem Quatsch mit den Geheimdiensten. Es gibt wesentlich einfachere Lücken, besonders die Wahlautomaten sind berüchtigte Scheunentore.
-
SeppJ schrieb:
dot schrieb:
Spectre noch Meltdown erlauben lediglich das Ausspionieren aber nicht das Manipulieren von Daten...
Die Idee ist doch, das Adminpasswort auszulesen, Sprungadressen zu finden, oder ähnliches. Und damit dann Rechte zu eskalieren, bis man volle Kontrolle, auch über die Daten, hat.
Und wie bekommst du diese tolle Software, die mit Hilfe von Spectre das Adminpasswort ausliest, auf die Wahlmaschine ohne das Adminpasswort?
Aber ja, mein Punkt war der selbe: Um Wahlmaschinen zu manipulieren braucht es weder Meltdown noch Spectre, das geht mit wesentlich einfacheren Mitteln...
-
dot schrieb:
Und wie bekommst du diese tolle Software, die mit Hilfe von Spectre das Adminpasswort ausliest, auf die Wahlmaschine ohne das Adminpasswort?
Aber ja, mein Punkt war der selbe: Um Wahlmaschinen zu manipulieren braucht es weder Meltdown noch Spectre, das geht mit wesentlich einfacheren Mitteln...
Eben, das war ja auch mein Punkt. Ich wollte dich unterstützen, wieso die Aluhuttheorie von computertrolls Unsinn ist.
-
-
Gibt es eigentlich unter Windows irgendeine Möglichkeit für den Anwender, dass er den CPU Microcode on the fly updated?
Also ohne erst das BIOS updaten zu müssen oder den microcode im Grub Bootloader zu laden?
Bei meinem Windows fehlt nämlich noch das Update für den Microcode, damit der Schutz gegen Spectre Variante 2 aktiv wird.
PS C:\Windows\system32> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: TrueSpeculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]Suggested actions
* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injectio
n mitigation.BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : FalseDas fette ist rot.
Für Spectre Variante 2 ist mein System unter Windows also noch anfällig.
Meltdown geht nicht mehr.
-
Übrigens, hier ist noch ein weiteres Tool mit dem man die Sicherheit des Systems ebenfalls bezüglich Meltdown und Spectre Variante 2 testen kann:
https://www.heise.de/download/product/specucheck
Wer das PowerShell Script ausführen möchte, der muss unter Windows 7 übrigens erst einmal schauen, ob er eine aktuelle PowerShell Version hat.
Das geht in der PowerShell mit dem Befehlget-hostSteht da bei Version eine 2 dran, dann ist die zu alt für das Spectre und Meltdown Testscript.
Um die Powershell upzudaten muss man aber erst einmal das .NET Framework 4.5 installieren, das ist nämlich für das Windows Management Framework 5.1 notwendig, die wiederum die PowerShell enthält.Anschließend kann man eine neue PowerShell Version installieren, in dem man das Windows Management Framework 5.1 installiert
https://www.microsoft.com/en-us/download/details.aspx?id=54616Windos 7 64 Bit Nutzer brauchen hier die Datei:
Win7AndW2K8R2-KB3191566-x64.zipIst alles installiert, dann sollte das Testscript in einer PowerShell mit Adminrechten funktionieren.
