Spectre und Meltdown

[hustbaer]

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]

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.

[computertrolls]

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.

[computertrolls]

AMD ist jetzt auch von Spectre 2 betroffen (bisher war es nur Spectre Variante 1):

https://www.heise.de/newsticker/meldung/AMD-rudert-zurueck-Prozessoren-doch-von-Spectre-2-betroffen-Microcode-Updates-fuer-Ryzen-und-Epyc-in-3939975.html

[computertrolls]

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.

[dot]

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...

[SeppJ]

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.

[dot]

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...

[SeppJ]

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.

[fdggfd]

Zu Linux: https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125-6.html

[computertrolls]

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/4074629

Hardware 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: True

Speculation 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 : False

Das fette ist rot.

Für Spectre Variante 2 ist mein System unter Windows also noch anfällig.
Meltdown geht nicht mehr.

[computertrolls]

Ü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 Befehl

get-host

Steht 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=54616

Windos 7 64 Bit Nutzer brauchen hier die Datei:
Win7AndW2K8R2-KB3191566-x64.zip

Ist alles installiert, dann sollte das Testscript in einer PowerShell mit Adminrechten funktionieren.

[computertrolls]

okay, hier gibt's ne Anleitung:

http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/

Das AMD Tool:
https://web.archive.org/web/20160320110218/http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2

Intel Microcode:
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

Wichtig, ihr benötigt beides.
Also auch das AMD Zeugs wenn ihr eine Intel CPU habt.
Im AMD Zeugs ist das dafür notwendige Tool enthalten.

[computertrolls]

Haswell, Broadwell und IvyBridge Besitzer sollten mit dem Update des Microcodes übrigens noch warten.
Da sind noch Fehler drin, die erst gefixt werden müssen.

Skylake Nutzer und später können das Microcode Update einspielen.

Außerdem muss es bei jedem Neustart geladen werden, falls es bei euch noch nicht im BIOS enthalten ist, es empfiehlt sich also in Autostart ein Skript zu starten, das das bewerkstelligt.

[Intel-User]

Irgendwie habe ich das Gefühl es herrscht nur noch Chaos. Die Informationspolitik der Hersteller und Unternehmen (Vorwiegend US-Firmen) ist erbärmlich zu diesem Thema und die Updates sind im Zuge der Sicherheit eine Verbesserung (Eher eine Grunderwartung!), doch eine Handbremse...

Ich habe mit Kollegen bei uns im Rechenzentrum selber auf mehreren Servern die Microcodes und Updates eingespielt und eines weiß ich jetzt schon: Die Rechnung wird hoch, da die Leistung sinkt. Das wird sich im PnL richtig zeigen...

Doch ich freue mich, dass ich hier nicht der einzige bin der leidet

Eben gefunden - wenn ihr mal zu dem Thema wenigstens mal etwas lachen wollt: https://www.it-madness.com/posts/531/

[computertrolls]

Hier habe ich mal ein Batch Script geschrieben, das euch die CPUID bzw. Signature der CPU und die Microcode Version des BIOS und, sofern manuell geladen, der manuell geladenen Version unter Windows anzeigt:

echo off
echo "CPUID/SIGNATURE (Model ist in Dezimalschreibweise):"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Identifier"
echo "Im Bios enthaltende Microcode Version:"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Previous Update Signature"
echo "Versionsnummer einer manuell geladenen Microcode Version: (falls leer = Fehlermeldung)"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Update Revision"

Das ganze einfach in einem Editor wie Notepad einfügen und mit der Dateinamenserweiterung ".bat" abspeichern.
Danach einfach in der Powershell oder Eingabeaufforderung starten.
Ich empfehle die Powershell, da man hier längere Zeilen ohne Zeilenumbruch darstellen kann.

Wer das Skript optimieren möchte, kann das gerne tun.

[computertrolls]

Mein Batch Script hat leider den Falschen Schlüssel ausgewertet, hier ist eine korrigierte Version.
Diese kann man auch per Mausklick starten, das Fenster bleibt danach noch geöffnet:

echo off
echo "CPUID/SIGNATURE (Model ist in Dezimalschreibweise):"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Identifier"
echo "Im Bios enthaltende Microcode Version:"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Previous Update Signature"
echo "Versionsnummer einer manuell geladenen Microcode Version: (falls leer = Fehlermeldung)"
reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ /v "Update Signature"
PAUSE

Das Microcode Update habe ich übrigens auch ausgeführt, allerdings scheint der Microcode nicht geladen zu werden.
Ich habe immer noch die gleiche Microcode Versionsnummer.

Und das Microcode Spectre Testscript prüft leider auch nur, ob ein neuer Microcode geladen wurde, aber nicht welcher.
D.h. mein Script zeigt jetzt immer noch die gleiche Version an:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
    Update Signature    REG_BINARY    00000000BA000000

Also BA, anzeigen müsste er aber für meinen Skylake den Wert C2 wenn das Laden des neuen Microcode geklappt hätte.

D.h. der Schutz ist noch nicht aktiv.

[computertrolls]

Hier sagt jemand, dass das manuelle Updaten des Microcodes zu später ausgeführt wird und somit wirkungslos ist:
https://www.reddit.com/r/sysadmin/comments/7pe2ew/intel_spectre_microcode_update/dsgrjgi/

Entweder das, oder das Problem liegt daran, dass dieses manuelle Update den neuen microcode erst gar nicht lädt, wie mein Script zeigt.

Vielleicht sind die Einträge in der Registry aber auch veraltet, das könnte auch sein, wobei dann aber nicht dieser neue Schlüssel "Update Signature" nutzlos wäre.

[computertrolls]

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.png

Das 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/4074629

Hardware 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: False

Speculation 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/4073119

BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False

PS 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.

[computertrolls]

Diejenigen, die den Microcode schon mit dem Bootloader laden wollen, finden hier eine Lösung:

https://biosbits.org/