Spectre und Meltdown
-
Update:
Okay, also ich habe jetzt extre HWINFO installiert um zu prüfen, ob der Eintrag in der Registry korrekt ist und das ist er nicht.
Denn HWINFO64 zeigt nun an, dass der neue Microcode C2 (der alte war B2) geladen ist.
https://www2.pic-upload.de/img/34657007/microcode_after_manual_update.pngDas ganze nützt aber nichts, da Windows beim Booten noch vom alten Microcode ausgeht, wie der Typ bei reddit.com richtig sagte und die Patches gegen Spectre somit nicht aktiviert werden:
https://www2.pic-upload.de/img/34657039/spectre_test_after_manual_microcode_update.png
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: True
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: FalseSpeculation 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
* Follow the guidance for enabling Windows Client support for speculation control mitigations described in https://supp
ort.microsoft.com/help/4073119BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : FalsePS C:\Windows\system32>
Das fette ist rot.
Das bedeutet also, den Microcode manuell unter Windows upzudaten bringt rein gar nichts.
Wenn man das tun will, dann müsste man das schon vor dem Booten von Windows machen.
Also entweder im BIOS oder im Bootloader (z.b. grub, keine Ahnung ob der das kann)Zumindest gilt das solange, solange Microsoft selbst keine Möglichkeit bietet, den Microcode on the fly upzudaten.
Übrigens:
Gimp scheint jetzt recht lange zum Laden zu benötigen. Das fühlt sich wieder so an, als hätte man eine Festplatte anstatt einer SSD.
-
Diejenigen, die den Microcode schon mit dem Bootloader laden wollen, finden hier eine Lösung:
-
IT-Sicherheit ist und bleibt eine Illusion, leider. In einer Gesellschaft in der Geld regiert wird immer der Rotstift angesetzt werden müssen und dies triff immer zuerst Sachen wie Sicherheit und Dokumentation. Macht eine Firma dies nicht zu genüge geht sie unter.
Genug Ressourcen für Sicherheit bereitzustellen ist also kein IT, sondern in erster Linie ein gesellschaftliches Problem.
-
|()| schrieb:
IT-Sicherheit ist und bleibt eine Illusion, leider. In einer Gesellschaft in der Geld regiert wird immer der Rotstift angesetzt werden müssen und dies triff immer zuerst Sachen wie Sicherheit und Dokumentation. Macht eine Firma dies nicht zu genüge geht sie unter.
Genug Ressourcen für Sicherheit bereitzustellen ist also kein IT, sondern in erster Linie ein gesellschaftliches Problem.
Die Probleme hat man bei Open Source Projekten, die nicht an Gelder gebunden sind, genauso.
Das Problem steckt einfach darin, dass Cracker immer einen Schritt weiter sind, man nur nachdackeln kann, die Entwicklertools mit vielleicht ein paar Ausnahmen selten beim sicheren Entwickeln unterstützen und die Gesellschaft leider auch viel zu wenig für Sicherheitspatches interessiert, geschweige denn diese ernst nimmt und darunter sind sogar die Entwickler selbst dabei.
Vor ein paar Tagen habe ich bspw. bei 3 Open Source Projekten eine Sicherheitslücke gemeldet. Der Bugreport wurde zwar von den Entwicklern in den Bugreports gleich akzeptiert und gesagt dass man das fixen müsse, aber kein Projekt hat es geschafft, ein neues Release oder wenigstens ein Minorrelease rauszubringen.
Die Stableversionen, die man sich downloaden kann, sind somit weiterhin alle anfällig.
Von Sensibilität bezüglich Sicherheit keine Spur.
-
Da kommt noch was.
Spectre und Meltdown waren erst der Anfang.
-
So schnell wie es gekommen ist verschwand es auch wieder. Sollte es zu Angriffen kommen wird man was darüber berichten, doch der große Sturm ist vorbei.
-
Der Seitenbetreiber hat allerdings das Problem von Spectre und Meltdown gar nicht verstanden.
Spectre und Meltdown machen nicht die Runde, weil diese Angriffstechniken einen "Fancy" Namen haben, sondern weil die Bugs in der Hardware stecken und die Lücken somit nicht einfach reparierbar sind.
Bei einer Sicherheitslücke in Software schreibt man nen Patch und das Problem ist behoben.
Bei Hardware geht das nicht. Da hat man entweder Leistungseinbußen, weil ganze Betriebssysteme umgeschrieben werden müssen oder der Bug ist nicht wirklich reparierbar, man kann nur versuchen die Symptome beheben.
Das ist etwas völlig anderes, als "Fancy" Names.
-
Für vieles gibt es keine Patches, und jetzt werden die die es gibt auch noch zurückgezogen.
Linus Torvalds ist nicht der einzige der sich über die Situation, sagen wir mal, amüsiert.
-
Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?
-
Facebook, Google, Amazon, NSA, Sesamstraße, Frau Merkel.
-
Erhard Henkes schrieb:
Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?
U.a. denke ich alle Hardwarehersteller, weil ja jetzt, überall dort wo die Patches eingespielt wurden/werden, für die selbe Workload mehr Hardware benötigt wird.
-
Erhard Henkes schrieb:
Welche Unternehmen werden von diesen Lücken mittelfristig profitieren?
Intel
-
ja, das klingt logisch. genau der gleiche effekt wie bei den diesel cars.
-
Verstehe ich nicht. War das denn bei den Dieseln so? Oder war das Sarkasmus?
Die Situation ist IMO allerdings nicht ganz vergleichbar, denn bei Meltdown/Spectre hat keiner geschummelt und es sind quasi alle CPUs betroffen. Zumindest alle mit guter single threaded Leistung.
-
ARM profitiert weniger als Intel, denn niemand tauscht sein Tablet oder Smartphone wegen Spectre aus. Genausowenig wird man sich im Embeddedbereich darum Gedanken machen.
Bei den Cloudservern sieht das schon ganz anders aus, da müssen die Unternehmen zwingend die HW gegen neue austauschen. Zum einen um die Leistungsverschlechterung durch die Patches auszugleichen und zum anderen um sie mittelfristig gegen CPUs zu ersetzen, die nicht mehr fehleranfällig sind.
Und diese Domäne gehört eben den x86 CPUs und Intel ist ihr größter Produzent.AMD wird zwar auch etwas vom Kuchen abkriegen, genauso wie es auch im Serverbereich sicher auch einige Spezialfälle für ARM CPUs gibt, aber das Groß an CPUs baut Intel, die können auch die Stückzahlen liefern.
AMD kann letzteres nicht und bei ARM ist der Servermarkt zu klein.Ebenso wird Intel recht schnell Lösungen anbieten können, immerhin haben die gleich mehrere Entwicklerteams und Intel kann im Notfall auch gleich mehrere CPU Designs erforschen. AMD kann das nicht.
Und ARM könnte es zwar, aber den Servermarkt haben die noch nicht wirklich so bedient, dafür fehlt oft noch die Leistung.Der ganz große Gewinner an Spectre und Meltdown ist somit Intel.
Den Vergleich zum Diesel finde ich unpassend. Denn da sind nur die Preise im Keller. Die Zukunft gehört kurzfristig eher den Benzinern und langfristig den E-Autos.
-
Gegen welche Hardware kann man denn tauschen?
Den Core i7 gegen i7-noSpectre?
-
Lukasi7 schrieb:
Gegen welche Hardware kann man denn tauschen?
Den Core i7 gegen i7-noSpectre?Praktisch gegen keine, theoretisch gegen einen ARM Cortex-A53 oder ARM Cortex-A55.
Praktisch deswegen gegen keine, weil der ARM Cortex-A53 bzw. ARM Cortex-A55 Meilenweit von der Leistung eines Core i7 entfernt ist.
Aber wenn dir Sicherheit absolut wichtig ist und die Leistung vernachlässigt werden kann, dann wäre er eine Option.Der ARM Cortex-A53 befindet sich bspw. im Raspberry Pi 3.
Sicher ist der deswegen, weil es sich um eine in-order CPU handelt, dies erklärt aber auch die geringe Leistungsfähigkeit.
-
Ergänzung:
Und natürlich kannst du darauf keine x86 Binaries nativ ausführen.
Wenn dir das wichtig ist, dann geht nur noch ein alter Atom auf dem Gebrauchtmarkt.Gut möglich, dass der Atom auch schneller ist.
-
@Lukasi7
Ich vermute computertrolls hat mit "mittelfristig gegen CPUs zu ersetzen, die nicht mehr fehleranfällig sind" gemeint: dann wenn die neuen, hoffentlich nichtmehr anfälligen Modelle verfügbar sind.
-
Bis die alten abverkauft sind wird es noch dauern. Bin mal gespannt ob und wann es die neuen Modelle geben wird, und wie sie gekennzeichnet sind.
