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

Jesterfox schrieb:
Ok, die Info war mir bisher noch nicht über den Weg gelaufen... aber irgendwie gibt's leider auch keine Stelle die mal sauber alle Fakten zusammenträgt. Wenn sich die verschiedenen Stellen dann noch widersprechen weil sie auf unterschiedlichem Stand was die Fakten angeht sind ist die Verwirrung halt komplett.

Doch gibt es und zwar in dem Artikel, zu dem du deinen Kommentar ablässt.
10-1080.971355446.png


Was Google erzählt und/oder verschiedene Seiten nachplappern, sind die Ideen wie man das Spectre Problem unter Linux zu lösen vermag. Microsoft nutzt die von Intel durch Microcodeupdates bereitgestellte neue Befehle.

Aus genau diesem Grund arbeitet AMD nun auch an Microcodeupdates und wird die gleichen Befehle unterstützen.
 
Zuletzt bearbeitet:
Das ist richtig.
Intel CPUs werfen die Exception für die negative Adressprüfung zu spät und die spekulativen OoO-Ausführungen können keine Exceptions generieren.
 
xexex schrieb:
Es wäre halt vorbildlich wenn es von anderen Herstellern auch ein einfaches Tool geben könnte womit man jetzt oder auch mal in der Zukunft einfach den Microcode aktualisieren könnte.
Der Mainboardhersteller? Wozu das denn? Um 3 Millisekunden schneller zu booten? Um Gefahr zu laufen, dass sich der Endnutzer beim Microcode-ins-BIOS-Patchen mit bischen Pech das Board schrottet? Solange der CPU-Microcode im BIOS ausreicht, um auf dem Rechner erfolgreich das OS zu starten, ist alles in Butter. Um den Rest kann sich das OS viel besser kümmern.

Intel stellt seit Ewigkeiten aktualisierte Microcodes für ihre CPUs ins Web und bietet ein Werkzeug um diese zu managen (iucode_tool). Das OS kann beim Start (also bei jedem Boot erneut) den aktuellen Microcode auf die CPU laden. Bei Debian sagt man z.B. "apt install intel-microcode" um alles automagisch einzurichten. Ab dem nächsten Boot des Rechners bekommt die CPU ihren aktuellen Microcode - ganz ohne auf Mainboardhersteller angewiesen zu sein. Dabei besteht keinerlei Risiko, sich das Board zu schrotten.
 
Zuletzt bearbeitet:
mensch183 schrieb:
Intel stellt seit Ewigkeiten aktualisierte Microcodes für ihre CPUs ins Web und bietet ein Werkzeug um diese zu managen (iucode_tool). Das OS kann beim Start (also bei jedem Boot erneut) den aktuellen Microcode auf die CPU laden. Bei Debian sagt man z.B. "apt install intel-microcode" um alles automagisch einzurichten. Ab dem nächsten Boot des Rechners bekommt die CPU ihren aktuellen Microcode - ganz ohne auf Mainboardhersteller angewiesen zu sein. Dabei besteht keinerlei Risiko, sich das Board zu schrotten.

Die Frage die sich aber stellt, aber der Microcode eben noch für Spectre 2 aktualisiert wird? Deine Möglichkeit wäre jetzt die für alle mit alter Hardware, deren Boardhersteller sich weigern, auf Linux (hier Debian) zu switchen, und so mit aktualisiertem Microcode zu leben?
Ergänzung ()

xexex schrieb:
Aus genau diesem Grund arbeitet AMD nun auch an Microcodeupdates und wird die gleichen Befehle unterstützen.

​Ich bin ja schon ein bisschen gespannt, ob sich das auf die Performance auswirken wird, sobald AMD Updates kommen ...
 
mensch183 schrieb:
Der Mainboardhersteller? Wozu das denn? Um 3 Millisekunden schneller zu booten?

Der Microcode wird meistens dann aktualisiert wenn sich Sicherheitslücken ergeben, Fehler in der CPU behoben werden müssen oder wie im vorliegenden Fall zusätzliche Funktionen nachgepatcht werden.

Die meisten Anwender würden ohne Spectre nie ein Update zu sehen bekommen und würden mit einer wesentlich gravierender Lücker unterwegs sein, dem IME Problem bei Intel.
https://www.computerbase.de/2017-09/intel-management-engine-sicherheitsluecke/

Microsoft hat wie Linux zwar die Möglichkeit ein Update zur Laufzeit einzuspielen, die Aktualisierung hält dann nur bis zum nächsten Neustart. Dumm nur das IME dauerhaft aktiv ist, auch wenn der PC ausgeschaltet ist. Das gleiche Problem gibt es auch auf der AMD Seite mit dem PSP.

Blöd ist, dass es von Biosherstellern durchaus Tools gibt, mit denen solche Modifikationen möglich sind. Dummerweise ist es den einschlägigen Webseiten aber untersagt worden, diese Tools in irgendeiner Form in Umlauf zubringen!
https://ami.com/en/products/bios-uefi-tools-and-utilities/

Es ist verständlich, wenn auch traurig, dass sich Mainboardhersteller nach zwei Jahren einen Dreck um ihre Boards kümmern. Dabei sind aktuelle EFIs alle Modular aufgebaut und könnten problemlos mit einem einfachen Tool zumindest in den sicherheitsrelevanten Bereichen aktualisiert werden.
 
Zuletzt bearbeitet:
Hat schon zufällig wer das UEFI-Update auf einem Asus Z170-A installiert und kann berichten, ob es zu Problemen gekommen ist oder nicht?
 
Also wie war das jetzt?

Wie sieht das aus mit den Banana Pis inklusive Router Modelle?
Jemand meinte nur die Raspberrys wären nicht betroffen.
 
Zuletzt bearbeitet:
Also wenn ich den Link von "Sepp Depp" Folge, dann wäre mein Core 2 Duo und Core 2 Quad nicht betroffen. Und meine beiden Notebook Core 2 Duo wären auch nicht betroffen. Das wäre ja erfreulich.
 
mach doch einfach mittels PowerShell die Abfrage. Dann siehst du es. Der Core2Quad Q8200 meiner Frau ist betroffen. Zumindest fördert PowerShell das so ans Tageslicht.

Naja sie lebt damit. ;)
 
Mir ist gestern etwas in den Sinn gekommen und wüsste gerne, was ihr davon haltet:



Soweit ich weiß, gesteht die Gefahr von Spectre für den Privatnutzer ja hauptsächlich darin, dass im Browser über Java-Script auf Informationen aus anderen Browser Tabs oder Daten der Session zugegriffen werden kann. Spectre ist ja Prozessgebunden.


Theoretisch könnte ich doch einfach Browser A für vertrauenswürdige Seiten (sensible Daten) verwenden und Browser B für alles andere. Da es sich um unterschiedliche Prozesse handelt, kann Spectre mWn dann nicht, wenn in Browser B ausgeführt, auf die Daten aus Browser A zugreifen.


Ist zwar umständlich, aber eigentlich eine gute Alternative gegenüber dem BIOS-Update, das ja doch teilweise nicht wenig Leistung kostet.

Was meint ihr? Oder habe ich da einen Denkfehler?
 
engine schrieb:
...
07.01.2018
Frank Riemenschneider

Fazit

Spectre Variante 2 ... Die gute Nachricht ist, dass ein Remote-Angriff nicht möglich ist.

Spectre Variante 1 ... Ein Remote-Angriff könnte theoretisch zwar möglich ein, aber in Praxis eher nicht, schon wegen der Frage, wie er von den relevanten Cache-Lines ein Timing-Signal zurückerhalten soll.
[FF und Crome kann man absichern, bzw. FF wurde schon. , soviel zu JavaScript]

Meltdown wird nach Implementierung der gezeigten Kernel-Page-Table-Isolation Geschichte sein. Derzeit arbeiten nicht nur alle bekannten OS-Hersteller, sondern auch Browser-Herseller an Fixes, denn auch Implementierungen in Java-Script waren laut den Forschern erfolgreich. Von den Auswirkungen ist Meltdown schon deshalb von allen Angriffsszenarien sicher am Katastrophalsten.
...

Ich überlese auch gerne etwas, aber das wurde schon zig mal erwähnt.
Bedeutet für mich, es muss (nach meinem jetzigem Stand) lokal eine Malware agieren.

Und ich würde generell JavaScript über Nocript oder uMatrix blockieren.
uMatrix korrekt konfigurieren, ist defaultmäßig falsch eingestellt.

Mehrere Browser halte ich nicht nötig.
Ergänzung ()

BrollyLSSJ schrieb:
Also wenn ich den Link von "Sepp Depp" Folge, dann wäre mein Core 2 Duo und Core 2 Quad nicht betroffen ...

Mein alter core 2 duo E6850:
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
 
Zuletzt bearbeitet:
Danke für die Info. Aber bevor ich komplett auf JS verzichte (hat ja auch seine Vorteile), nutze ich lieber zwei Browser.


Wenn das so funktioniert, sehe ich dann keinen Grund, das BIOS mit neuem Microcode zu aktualisieren und über 40% der 4k etc. SSD-Leistung zu verlieren.



Mit FF und Chrome gibt es ja zwei sehr brauchbare Browser. Damit komme ich klar. :)
 
Zuletzt bearbeitet:
inge70 schrieb:
mach doch einfach mittels PowerShell die Abfrage. Dann siehst du es. Der Core2Quad Q8200 meiner Frau ist betroffen. Zumindest fördert PowerShell das so ans Tageslicht.
Das habe ich auch schon längst getan. Wegen dem WU ist das eine Ding auch "grün", was es vorm Update nicht war. Auf der Seite sagten die aber auch, dass es eventuell betroffen sein kann, aber nicht so schlimm wie die anderen CPUs.

engine schrieb:
Mein alter core 2 duo E6850:
Meine sehen genauso aus.
 
Sepp Depp schrieb:

Wenn die Liste komplett ist, wären Core 2 Duo (Conroe) und Core 2 Quad (Kentsfield) ja wirklich nicht betroffen. :)

EDIT: Sorry, das war jetzt etwas doppelt. Hätte die Seite nach der Pause wohl vorher noch aktualisieren sollen. Prüft das PowerShell Skript denn tatsächlich auch, ob die Lücke bei der installierten Hardware existiert, oder nur, ob das Betriebsystem gepatcht werden muss?
 
Zuletzt bearbeitet:
MrJules schrieb:

In chrome kannst du "strict site isolation" aktivieren: chrome://flags/#enable-site-per-process
Das Internet ist ohne JavaScript weitgehend sinnlos, aber du kannst JS aktivieren für deine vertrauenswürdigen Seiten, die JS selber kontrollieren, für alle anderen Seiten oder Seitenelemente JS blockieren, ist aber auch ohne "Meltdown, Spectre" Standard!
 
Zuletzt bearbeitet:
Danke für den Hinweis! :)


Hab ich zufällig auch gerade entdeckt.

https://support.google.com/chrome/answer/7623121?hl=en-GB




Wenn man das so machen kann ohne BIOS Update, wozu dann noch das BIOS-Update mit neuem Microcode auf Privatsystemen unter Windows?


Für Meltdown ja nicht und für Spectre bleiben dann wohl nur noch die noch exotischeren Angriffsszenarien.
 
Zuletzt bearbeitet:
MrJules schrieb:
Wenn das so funktioniert, sehe ich dann keinen Grund, das BIOS mit neuem Microcode zu aktualisieren und über 40% der 4k etc. SSD-Leistung zu verlieren.

Wo im realen leben nutzt du denn Exzessive einen I/O-Zugriff mit nur 4K "massiv" ?
Hast du etwa privat Zuhause Datenbanken bestehend aus millionen von winzigen Dateien ?

Real wirst du vielleicht 10% Einbuße sehen in extremen Fällen 20%.

Mit AgentRansack kannst du das mal leicht auf deinen Platten nachschauen:
https://www.sevenforums.com/general-discussion/261860-average-file-size-statistics.html
Nachtrag:

When does user-mode code make a kernel-mode call?

You might think that any time code called one of the so-called ‘Win32’ APIs that effectively make up the operating system, that this would result in a kernel-mode call. In fact, this is not the case. A lot of API calls are serviced entirely in user mode. For example, requesting the current tick count with the GetTickCount () API is entirely serviced in user mode. Conversely, closing a file handle requires a kernel-mode call.
If you profile a process with performance monitor and the % privileged time for that process is a significant amount, that process is potentially vulnerable to performance issues after applying the meltdown patch. If, on the other hand, the process makes few kernel calls (i.e % privileged time is consistently very low) then that process is unlikely to experience a performance slowdown because of applying the patch.
Quelle: https://www.1e.com/blogs/2018/01/09/predicting-meltdown/

Es betrefft eben nur diejenigen syscalls die einen Context Switch (user <=> kernel) machen... ! Also nicht alle syscalls sondern nur einen Teil.
Nachtrag-Ende


Ich hab Beispielsweise auf meinem Arbeitsplatzrechner hier:

Stats_C.png

Wenn ich also nun ein Gesamtbackup meiner Platte mache ist nur ca 1/3 der Files davon I/O operationen mit File Sizes <4KB....bei Größeren I/O operation ist der Performance drop viel kleiner...(sieh CB Test).

Und das OS zu backupen ist oft schon der "Worst Case" was die File Sizeverteilung betrifft.

Beachte:
Als deutlich gravierender erweisen sich hingegen die Gegenmaßnahmen für Spectre: Über 40 Prozent Durchsatz verliert die SSD beim wahlfreien Lesen und Schreiben kleiner Blöcke über einen Thread
Mit größeren Blöcken ist der Verlust entsprechend kleiner bis nahezu 0. Ab 4k Blöcken beginnt aber eine kritische Größe bei der die Performance drastisch einbricht.

EDIT: Ah hier mal von leuten mit mehr Übersicht eine kleine "erwartungsgröße" der Impacts (auf Linux aber Windows wird ähnlich sein)
https://www.servethehome.com/red-hat-outlines-meltdown-spectre-patch-performance-impacts/
 
Zuletzt bearbeitet:
MrJules schrieb:
...
Für Meltdown ja nicht und für Spectre bleiben dann wohl nur noch die noch exotischeren Angriffsszenarien.

Das sehen wir in den kommenden Monaten.
Für alte CPUs hast du fast keine andere Wahl, also wirst du wohl ohne Microcode-Update klar kommen müssen.
Für neuere CPUs musst die einfach probieren, ob die Performance wirklich einbricht für deine apps,
zudem gibt es hier keinen Fix, sondern nur eine Milderung der Angriffsmöglichkeiten.
 
Zurück
Oben