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

Iscaran schrieb:

Ist also nicht Linux spezifisch - das OS und die Software müssen halt mit nem entsprechenden C++ compiler neuübersetzt werden.

Zum Vergrößern anklicken....

Es ist nicht Linux spezifisch, ABER Windows betrifft es nicht!

GCC as well as Clang/LLVM, the major open source compilers, now have support for generating such retpolines, while Windows and Visual Studio are not currently pursuing this approach.
https://www.crowdstrike.com/blog/ch...vulnerabilities-and-proving-hard-to-mitigate/

Zum Vergrößern anklicken....

Unter Windows wäre es sinnlos für den Schutz darauf zu bestehen, die Software neu kompilieren zu müssen. Die meiste Anwendersoftware wird nie ein solches Update zu sehen bekommen und wäre unsicher.

Die Änderungen am Compiler seitens Microsoft beziehen sich, wie du selbst bereits treffend angemerkt hast, NUR auf Spectre 1.
https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

Die Aussage "Windows AND Visual Studio" sollte man auch so verstehen wie es gemeint ist. Windows bietet keine Unterstützung für Retpoline, Software die für Windows kompiliert wurde somit auch nicht.

So wie ich das verstehe wird das so umgesetzt dass die Software einen "Flag" setzen kann. (bzw. das automatisch erkannt wird mit welchem Compiler das umgesetzt wurde und ob dieser Retpoline "aware" ist.

Wenn JA => dann Schutz über "Retpoline" mit weniger Performance impact.
Wenn NEIN => dann Schutz über Microcode Update + OS Eintrag IBRS / IBPB und co zu nutzen, was mehr Performance kostet.

(Auf AMD läuft das dann via Microcode Update + OS Eintrag LFence zu nutzen ?) Oder ist die Nutzung der LFENCE instruktion die entsprechende Compiler-Patch-Variante auf AMD-CPUs - ist mir grad auch noch nicht ganz klar ?)

Miuwa schrieb:

...

Zum Vergrößern anklicken....

Generell wird wenig durcheinander geworfen, nur muss man auch die ganzen Infos hier lesen ^^ .
Erst dann bekommt man einen ungefähren Überblick.

Hier im Artikel unter:
Update 09.01.2018 23:24 Uhr
Leistungseinbußen unter Windows 7/8 größer als unter Windows 10

Wenn das reicht.

@xexex: Lies mal die Google Beschreibung was Retpoline ist.
Das ist alles nur über Compiler ! Aber es reicht wohl wichtige OS-Bestandteile zu rekompilieren, da User-Software eigentlich nie direkt in den Kernel kommuniziert sondern immer über das OS geht ?

Also nochmal. Microsoft setzt auf die langsame Variante und behebt Spectre 2 immer mit einem Leistungsabfall. Retpoline wird nicht angewendet. Spectre 2 ist unter Windows mit entsprechenden Patches abgehakt und kostet Leistung. Aus genau diesem Grund bietet AMD nun auch Microcode Update an und Microsoft wird mehr oder weniger die gleichen CPU Befehle zur Mitigation von Spectre 2 auf beiden Plattformen nutzen.

Retpoline ist der Ansatz von Linux um nicht so viel Leistung zu verlieren, es benötigt Unterstützung vom System UND Applikationen und ist in Arbeit. Ein Schutz gegen Spectre 2 ist unter Linux noch nicht fertig implementiert.

LFENCE ist Schutz gegen Spectre 1. Die Änderungen am Compiler von Microsoft sind einzig darauf zurückzuführen, die Spekulation auf Reddit gab es, solange Microsoft nicht öffentlich gemacht hat, was sie geädert haben.

Mitigating variant 1

Software changes are required to mitigate variant 1 on all currently affected CPUs. This can be accomplished by employing instructions that act as a speculation barrier. For Intel and similar processors (including AMD) the recommended instruction is LFENCE. ARM recommends a conditional move (ARM) or conditional selection instruction (AArch64) on some architectures and the use of a new instruction known as CSDB on others. These instructions ensure that speculative execution down an unsafe path cannot proceed beyond the barrier. However, applying this guidance correctly requires developers to determine the appropriate places to make use of these instructions such as by identifying instances of variant 1.

In order to help developers mitigate this new issue, the MSVC compiler has been updated with support for the /Qspectre switch which will automatically insert one of these speculation barriers when the compiler detects instances of variant 1. In this case the compiler detects that a range-checked integer is used as an index to load a value that is used to compute the address of a subsequent load. If you compile the example above with and without /Qspectre, you will see the following code generation difference on x86:
https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

Zum Vergrößern anklicken....

Iscaran schrieb:

Aber es reicht wohl wichtige OS-Bestandteile zu rekompilieren,

Zum Vergrößern anklicken....

Es ist egal was Google schreibt, Microsoft nutzt es nicht. Mehr bleibt unter dem Aspekt derzeit nicht zu sagen. Microsoft könnte es vielleicht mal irgendwann in der Zukunft implementieren. Im Moment ist das was Google schreibt und jegliche Spekulation darüber, für Windows Nutzer nichtig.

Hier auch nochmal die Erklärung dazu.

Gegen die Sicherheitslücke Branch Target Injection (Spectre Variante 2, CVE-2017-5715) gibt es zwei Schutzverfahren. Beide verlangen bei Intel-Systemen ein Zusammenspiel von Updates des Betriebssystems mit CPU-Microcode-Updates, die neue Funktionen der Prozessoren freischalten.

Das erste BTI-Schutzverfahren verwendet drei neue CPU-Befehle, die Intel bei nicht näher genannten "modernen Prozessoren" per Microcode-Update nachrüstet: Indirect Branch Restricted Speculation (IBRS), Single Thread Indirect Branch Predictors (STIBP) und Indirect Branch Predictor Barrier (IBPB). Sie sollen auch in alle Prozessoren kommender Generationen eingebaut werden. Die genaue Dokumentation will Intel in einer künftigen Revision des Entwicklerleitfadens "Intel 64 and IA-32 Architectures Software Developer’s Manual" nachreichen.

Bei der zweiten BTI-Schutztechnik ersetzen Programmierer bestimmte Sprungbefehle durch ein Konzept namens "Return Trampoline" (Retpoline). Das funktioniert bei Intel-Prozessoren ab der Generation Broadwell (2015: Core i-5000, Xeon E5 v4) wiederum erst nach einem Microcode-Update. Letzteres wird üblicherweise per BIOS-Update eingespielt, einige Linux-Distributionen bringen aber auch Microcode-Updates mit. [/ Update]
https://www.heise.de/newsticker/mel...estaetigt-Performance-Auswirkung-3936956.html

Zum Vergrößern anklicken....

Microsoft nutzt ausschließlich Variante 1

EDIT:
Verstehen kann man die Entscheidung schließlich auch!

Die Lösung von Google funktioniert (am besten) mit neuer und/oder gepatchter Software auf alten Plattformen. Eine Schnittmenge die es unter Windows so nur selten gibt, da der Quellcode großenteils Closed Source ist.

Die Lösung von Microsoft brilliert hingegen auf aktuellen Plattformen auch (aber nicht nur) mit alter Software. Etwas was man hier schon eher vorfinden wird und bestehende "alte" Software ohne Anpassungen schützt. Zudem kann Intel ja in zukünftigen CPUs die bereitgestellten Befehle optimieren.

Ah - OK. Danke für die Zusammenfassung.

Hier ist das nochmal sehr schön zusammengefasst:
https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9

@xexex

​Danke für die Zusammenfassung! Schön wenn hier jemand den Überblick behält (Steffen scheint sich ja zu sehr über seine neuen Serve rzu freuen ;-)

Ouch...@xexex:
https://arxiv.org/pdf/1801.04084v1.pdf
Die Publikation ist von 12.01.2018.

Das ist zwar wenn ich das richtig verstehen nicht direkt Spectre - eher Meltdown (bzw. eine Variante davon ?) da es auf einen Bruch von ASLR hinausläuft. Auch reden sie davon wie man mit der Methode aus einer VM ausbricht => Meltdown ?
Besonders interessant ist hier Kapitel 6A das auch konkrete Angriffswege via Browser und Co benennt.

Wir hatten das ja glaub in dem anderen Topic diskutiert "wie lange" so eine Attacke dauern muss um irgendetwas an Daten zu liefern. Und dein Hauptargument war dass man relativ lange scannen müsste um zu wissen welche daten wo liegen etc.
Interessant an dem obigen Paper ist nun, dass hier die Autoren die Zeitskala nennen die es dauert eine beliebige 2MiB-Kerneladresse zu lokalisieren.

Nämlich nur wenige sekunden (~2.63s im Mittel). (@Linux)
Mit Meltdown sind denk ich ganz ähnliche "Angrifsszeiten" denkbar! Und die Autoren schreiben weiter dass Sie noch nichtmal versucht haben hier noch zu optimieren in der Hinsicht

That is, note that we did not strive towards decreasing the search time, in order to find a generic
solution that works with any kernel image size (even smallones). Still, using this na¨ıve search, we reliably find every mapped 2MiB kernel page in 2.63 seconds on average.

Zum Vergrößern anklicken....

Für Windows KASLR brauchten die Herren sogar nur ca. 0.5s

Running the experiment 100 times showed that the kernel image area in Windows can be found in under a second (0.55s) on average.

Zum Vergrößern anklicken....

Für das Prime X299-A gibt es jetzt ein neues BIOS(1102).
Natürlich hat man bei ASUS nicht zeitgleich die IME SA00086 Lücke geschlossen..Saftladen.

Dafür habe ich mal ein hochgeladen wenn es jemand braucht verlinke ich es neu okay.

Laut heise gibt es anscheinend nun auch Updates für 32 Bit Windows.

Die gab es zuvor auch schon für spectre 2, Meltdown Fehlanzeige.
Über die automatische Updates wired mir jedenfalls nichts angeboten.

Besitzer der von den Bootproblemen betroffenen älteren AMD-Systeme mit Windows 7 und 8.1 lässt Microsoft experimentieren: Zwar stehen Downloads für solche Systeme bereit (KB4073576 für Windows 8.1, KB4073578 für Windows 7), doch ob diese die fehlerhaften Updates ersetzen oder ergänzen, verrät Microsoft nicht. Anhand der Download-Größen in Microsofts Update-Katalog lässt sich immerhin erahnen, dass sie einfach die fehlerhaften Security-Only-Pakete von Anfang Januar ersetzen (KB4056898 bzw. KB4056897)

Zum Vergrößern anklicken....

/edit: installiert, nix meltdown patch
Ich glaub, ich schmeiß den ganzen Mist wieder runter.

OK, weil ich nichts darüber hier gelesen hatte und heise die News ja erst vorgestern schrieb.

kisser schrieb:

Ich glaub, ich schmeiß den ganzen Mist wieder runter.

Zum Vergrößern anklicken....

Bis auf KB4056894 (monatliches Rollup) alles runtergeworfen, Status bzgl. Spectre/Meltdown immer noch unverändert.
MS hat´s echt voll drauf

kisser schrieb:

MS hat´s echt voll drauf

Zum Vergrößern anklicken....

Sofern Micosoft überhaupt in der Lage ist, das Microcode Update vor dem Kernel zu laden, dürften die es sich zweimal überlegen, für Intel/AMD in die Bresche zu springen und das zu tun (Der bisherige Plan war ja: Intel liefert Microcode aus und Motherboard Hersteller bringen neues UEFI raus). Denn dann wäre MS auf einmal Schuld an Intels/AMDs Problemen in den Augen der User. Das sieht man ja hier an Deinem Post.

Es geht mir um Meltdown, das ist reine Sache des OS.
Ein Microcode-Update für meinen alten Core2 wird sowieso nicht kommen, da bin ich mir ziemlich sicher.

kisser schrieb:

Es geht mir um Meltdown, das ist reine Sache des OS.
Ein Microcode-Update für meinen alten Core2 wird sowieso nicht kommen, da bin ich mir ziemlich sicher.

Zum Vergrößern anklicken....

Es wird OS-seitig gefixt, ist aber ein HW Problem ;-)

kisser schrieb:

Es geht mir um Meltdown, das ist reine Sache des OS.
Ein Microcode-Update für meinen alten Core2 wird sowieso nicht kommen, da bin ich mir ziemlich sicher.

Zum Vergrößern anklicken....

OK dann sorry! Ja das MC Update für Spectre wird wohl höchstes noch für Sandy kommen (Erst hieß es ja nur bis Haswell runter).
Naja mal schauen, ob sich noch etwas ergibt,

Solange es keine neue "sicherere"* CPU-Architektur gibt, bleibe ich un-gemildert, ich kaufe sicher keine neuere CPU-Architektur, bei der Situationslage.

Gibt es eigentlich schon eine gezielt arbeitende Malware in freier Wildbahn, die gegen private los geht, also keine Labor-Malware?
Ich beobachte die Situation schon länger nicht mehr, wie sonst auch üblich. Alles verschwimmt und wird nach 2 Wochen vergessen, wenn es nichts katastrophales zu dem Thema mehr gibt.

* nicht so kompromisslos unsichere

Hätte es Intel wissen können/müssen?

https://twitter.com/TheSimha/status/949361495468642304