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

Für Win7 gibts nun 2 Patches
https://www.deskmodder.de/blog/2018/01/04/kb4056897-windows-7-sicherheitsupdate/

KB4056897
und
KB4056894

Werde jetzt mal ein IMAGE erstellen bevor ich weiter experementiere

Bis jetzt siehts so aus

SpecuCheck v1.0.3 -- Copyright(c) 2018 Alex Ionescu
https://ionescu007.github.io/SpecuCheck/ -- @aionescu
-------------------------------------------------------

Mitigations for CVE-2017-5754 [rogue data cache load]
-------------------------------------------------------
[-] Kernel VA Shadowing Enabled: no
├───> with User Pages Marked Global: no
├───> with PCID Support: no
└───> with INVPCID Support: no

Mitigations for CVE-2017-5715 [branch target injection]
-------------------------------------------------------
[-] Branch Prediction Mitigations Enabled: no
├───> Disabled due to System Policy: no
└───> Disabled due to No Hardware Support: yes
[-] CPU Supports Speculation Control MSR: no
└───> IBRS Speculation Control MSR Enabled: no
[-] CPU Supports Speculation Command MSR: no
└───> STIBP Speculation Command MSR Enabled: no

Sagt uns nun was genau?

Helfen da beide Patches und die manuelle Aktivierung in der Registry?
 
Zuletzt bearbeitet:
Diese Verbreitung von Meltdown, bzw. die riesige Anzahl der betroffenen Prozessoren in denen sich der Fehler findet, ist ja absurd. Hat da seit 1995 niemand mehr mit Verstand draufgesehen und die betroffene Einheit (afaik geht es ja um die Out-of-order execution, weshalb auch die alten Atoms davon nicht betroffen sind*) wurde per <STRG>+<C> und <STRG>+<V> einfach in jedes neue Design implementiert?

Oder wusste man bei Intel irgendwann sehr wohl, was für ein Ei man sich da gelegt hatte, konnte aber aus Performancegründen (mglw. andere Compiler für neuentwickelte Ooo exe Einheit notwendig oder eine sauberes Design wäre prinzipiell langsamer?) gar nicht zurück/wäre in Erklärungsnot geraten?

Aber unabhängig von der Vorgeschichte:
Die Kirsche auf der Sahne auf dem Eisbecher ist, dass man sich bei Intel hinstellt und behauptet, dass der Bug kein Bug sei, sondern alles so wie vorgesehen funktioniere. Das dieses Verhalten aber nicht dem Konstrukt Ooo Execution inhärent ist, sondern das das tatsächliche Problem durch deren "exactly as it is designed to" Implementierung entstanden ist, will man natürlich nicht zugeben.

Is this a bug in Intel hardware or processor design?

No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

*Das erklärt auch, warum die Out-of-order execution bei AMD fehlerfrei funktioniert. Nach dem Design des 80486er, den AMD ja noch weitestgehend unverändert nachbauen durfte, mussten sie mit dem K5, der erstmals Out-of-order execution beherrschte, ein vollständig eigenständiges Design entwickeln. Der K6, der wiederrum auf dem NexGen Nx686 beruhte, war ebenfalls losgelöst von Intel entwickelt worden. Es gibt also seit dem 80486er keine direkte Verbindung mehr zwischen AMD und Intel, weswegen die beiden Ooo execution Einheiten wohl tatsächlich anders arbeiten.
 
Zuletzt bearbeitet:
Hi Krautmaster

Immer mehr komplexe Kerne auf eine Die zu bringen, wird immer aufwendiger und teurer. Je kleiner die Strukturen auf dem Silizium werden, desto anfälliger wird allgemein das, was ich in das Silizium hereinätzen will. Die Gefahr, dasss durch Fehlstellen im Silizium ganze Bereiche unbrauchbar werden, steigt. Die Ausfallrate wird bei sehr großen Chips wird immer größer. Nvidia hat dies vor Kurzen sogar deutlich gesagt, dass man sich dem Ende der Fahnenstange immer mehr nährt. Derzeit steht keine andere Technologie bereit, um diese Grenzen wirtschaftlich zu durchbrechen.
Das heißt, je mehr komplexe Chips (viele viele Kerne + Peripherie) ich auf das Silizium ätze, eh höher wird der Aufwand. Das schlägt sich auch im Verkaufspreis nieder. Sicherlich wird es dafür Spezialanwendungen geben, aber es ist keine große Option für die Zukunft mehr. man sieht welche Probleme Intel mit seiner 10nm Fertigung hat. Die Probleme werden in Zukunft nicht kleiner.

Die Interposer- Technologie, wobei Intel die auch schon sehr früh angewendet hat, gehört eher die Zukunft, für sehr große Chips. Sicherlich gibt es Verluste, durch die längeren Laufwege, auch in größeren Mesh-Netzwerken kommt es zu Verlusten. Vorteil der Interposer- Technologie ist halt die effiziente Ausnutzung der Die und deren Prozess. Ich brauche keine riesen Die ätzen und kann verschiedene Die zu einem Komplex kombinieren. Letztendlich schlägt es sich im Preis nieder.
Wer das Rennen macht, wird der Preis entscheiden.
Gruß
 
Das riecht nach wir gehen den schnelleren (anfälligeren) Weg und hoffen das niemand es aushebelt gegen wir gehen den sicheren weg aber verzichten etwas auf Leistung.

Edit: Die Intel 10nm Problematik sehe ich jetzt in einem anderen Licht, ich denke eher das die das als Vorwand nutzen um die Architektur zu überarbeiten, deswegen auch das fast streichen von Cannon-Lake.
 
Zuletzt bearbeitet:
oldmanhunting schrieb:
AMD ist diesmal nicht betroffen, weil die es nicht geschafft haben diese Vorhersage Logik, die es bei Apple, Google, Intel und bei wem sonst noch gibt nicht in die CPU zu bringen.

Oh Mann, gleich vielfacher Unsinn in einem Satz.

Es geht nicht um die Branch Prediction, sondern um Speculative Execution (Teil/Erweiterung der out-of-order exeution).
AMD hat OoOE schon vor 20 Jahren "geschafft" [1].
Unter ganz speziellen Umständen ist zumindest AMD Bulldozer von Spectre betroffen (im Labor, mit einer künstlichen Nicht-Standard Linux Kernel-Konfiguration), eben weil er Speculative Execution macht.
Google baut keine Prozessoren, hat die "Logik" also gar nicht



[1] https://en.wikipedia.org/wiki/Out-of-order_execution
 
HasseLadebalken schrieb:
Ich...


Gruss Dennis

Hab ich dann falsch verstanden, sorry meinerseits .. Und Linux ist nicht mein Gebiet xD Ubuntu bekomme ich so grade installiert, das wars dann. Und klar geht nur abklopfen bis man Lücken findet. Eigentlich echt spannend.

Hier der Artikel: https://www.google.de/url?sa=t&sour...vC3IQFggfMAA&usg=AOvVaw0vUvGParJ9_uWXs2iph7KZ

Die Publikation der Tu Graz müsstest du dir bitte sonst hier raussuchen oder Google... Liest sich sehr interessant
 
Zuletzt bearbeitet:
@ CB: Dann testet nochmals in einigen Wochen die Spiele und Co.
Dann ist wohl AMD vorne^^. (trotz schlechterer Treiber und ohne "Feature")
 
Zuletzt bearbeitet:
Ich vermisse die alten Zeiten, wo noch sehr viele Woltlab 2.3.6 Forum mit mysql Datenbanken verwendet haben, ich hatte eine Kiddie Resident Evil Fan Seite und auf ein mal hatte ich keine Konkurenten mehr.

Da mein Windows Pc noch nie eine Internet Verbindung aufgebaut hat, habe ich nichts zu befürchten.
 
emulbetsup schrieb:
Diese Verbreitung von Meltdown, bzw. die riesige Anzahl der betroffenen Prozessoren in denen sich der Fehler findet, ist ja absurd. Hat da seit 1995 niemand mehr mit Verstand draufgesehen und die betroffene Einheit (afaik geht es ja um die Out-of-order execution, weshalb auch die alten Atoms davon nicht betroffen sind*) wurde per <STRG>+<C> und <STRG>+<V> einfach in jedes neue Design implementiert?

Das Problem hat nicht Intel allein verbockt, die OS Hersteller sind hier ebenfalls Schuld. Im Grunde genommen hat bis heute schlichtweg "niemand" daran gedacht diese Eigenschaft der Prozessoren auf diese Weise zu missbrauchen, obwohl die Möglichkeiten seit Jahren bekannt sind.

Ich empfehle dazu den hervorragend geschriebenen Beitrag von Andreas Stiller auf Heise.de.
Am einfachsten kann man das Problem bei der sogenannten Meltdown-Attacke erkennen. Diese nutzt zwei Dinge aus: eine Spezialität der Intel-Prozessoren (Liste der betroffenen Prozessoren) und eine der üblichen Betriebssysteme wie Linux, Windows macOS ...

Aus Performancegründen mappen diese den Adressraum des Kernels und darüber hinaus den des ganzen (sichtbaren) physischen Speichers in der Seitentabelle jedes User-Prozesses, wenn auch geschützt mit einem Supervisor-Bit, so dass der User-Prozess selbst darauf nicht zugreifen kann. Wenn also ein Befehl wie MOV AL,[RCX] auf eine Kerneladresse zugreift, gibt es eine Exception – doch die dauert. Die Zeit kann man noch verlängern, wenn man vorher dafür sorgt, dass die Seitentabelle nicht im Cache residiert und/oder der TLB zuvor gelöscht wird.

Bis der Prozessor erkannt hat, dass er auf eine verbotene Adresse zugreift, hat er jedenfalls bei den Intel-Prozessoren schon mal AL von eben dieser verbotenen Adresse geladen. Und in der Zwischenzeit kann man transiente Befehle ausführen, die abhängig vom Wert in AL das Cache-Layout ändern. Wie man dieses Cache-Layout dann real auslesen kann, also welche Adressen dort gespeichert sind – dazu gibt es schon seit vielen Jahren bewährte Algorithmen wie Flush-Reload (falls ein clflush-Befehl existiert) oder Evict-Reload (falls nicht), die alle eine möglichst präzise Zeitmessung benötigen. Über diesen „covert Channel“ morst man also ein paar Bits aus der Innenwelt des Prozessors nach draußen.
https://www.heise.de/newsticker/mel...ectre-sind-ein-Security-Supergau-3935124.html

Es wurde bereits seit 1992 darüber gesprochen und auch publiziert.
https://dl.acm.org/citation.cfm?id=2117741

The possibility of cross-process leakage via cache state has been mentioned in several previous
works. It was considered in 1992 by Hu [8] in the context of intentional transmission via covert channels. In 1998, Kelsey et al. [9] mentioned the prospect of “attacks based on cache hit ratio in large S-box ciphers”. In 2002, Page [10] described theoretical attacks using cache misses, but assumed the ability to identify cache misses with very high temporal resolution; its applicability in realistic scenarios is unclear. In 2002 and 2003, Tsunoo et al. [16][17] described attacks using timing effects due to collisions in the memory lookups inside the cipher, as opposed to the cipherattacker collisions we investigate.
https://www.cs.tau.ac.il/~tromer/papers/cache.pdf
 
Zuletzt bearbeitet:
xexex schrieb:
Das Problem hat nicht Intel allein verbockt, die OS Hersteller sind hier ebenfalls Schuld. Im Grunde genommen hat bis heute schlichtweg "niemand" daran gedacht diese Eigenschaft der Prozessoren auf diese Weise zu missbrauchen, obwohl die Möglichkeiten seit Jahren bekannt sind.

Der Artikel ist da allerdings nicht genau genug. XNU (der Kernel von Darwin welcher wiederum der Kernel von macOS / iOS ist) hat die Trennung von Kernel und Userspace schon immer vorgenommen, nur nie richtig. Da diese Art des Missbrauchs bisher nicht möglich/bekannt war.

Daher musste es zumindest für Meltdown nur ein kleinen fix bei XNU geben. Nur Meltdown wird es bei XNU auch so gut wie keine Geschwindigkeitsverluste geben. XNU war da einfach schon immer langsamer als Linux und der NT-Kernel. Für weitere Infos ganz interessant Seite 46 - 48:

https://events.ccc.de/congress/2007/Fahrplan/attachments/1053_inside-macosx-kernel.pdf
 
Zuletzt bearbeitet:
Gerade noch mal Stichproben bei Asus gemacht, es scheint das mittlerweile bis runter zu H110 Boards alles mögliche mit Updates versehen wurde. Die 8er und 9er Generationen bisher gar nicht. Hoffe da kommt noch was von Asus.
 
Also der Windows Patch von gestern hat mein System (gefühlte Praxis) nicht verlangsamt. Ich merke im Alltag nichts.
 
Ja mag sein, aber was ein sythentischer Benchmark ausgibt interessiert mich nicht. Es würde mich dann stören wenn ich in der reellen Nutzung einer Applikation eine Verschlechterung festellen würde.
 
Ich gehe davon aus, das man noch Updates nachschiebt um das Ganze zu optimieren.
Allerdings läuft es doch optimal, jetzt kann man die nächste Generation Prozessoren mit dem "Sicherheitshinweis" noch besser vermarkten.
Aber sowas wird ja NIE vorsätzlich gemacht ....
 
Wo sehe ich ob ich das Update schon habe? Im Update Verlauf steht das er folgende Version installiert hat : Version 1709. Ist es das?
Hab win 10
 
Artikel-Update: Hinweise zu dem PowerShell-Script
Falls die Installation oder das Ausführen des im vorigen Update erwähnten PowerShell-Scripts Probleme bereiten, dann sollten Windows-Nutzer darauf achten, die PowerShell als Administrator auszuführen (Rechtsklick → „Als Administrator ausführen“). Falls das noch nicht den gewünschten Erfolg bringt, kann der folgende PowerShell-Befehl helfen: PS > Set-ExecutionPolicy -ExecutionPolicy RemoteSigned. Generell muss PowerShell mindestens in Version 3.0 installiert sein.

Alternative zu dem PowerShell-Script
Als Alternative zum offiziellen Weg kann auch das ohne weitere Umstände über die Windows-Eingabeaufforderung cmd.exe ausführbare Tool SpecuCheck (Download der EXE-Datei) von Alex Ionescu genutzt werden.

Dazu öffnet man im Startmenü durch Eingabe von „cmd.exe“ die Eingabeaufforderung und gibt dort „SpecuCheck“ ein. Die heruntergeladene Datei muss zuvor direkt im Ordner „Eigene Dateien“ platziert worden sein, alternativ wechselt man mittels cd-Befehl in das jeweilige Verzeichnis. (Startet man die EXE-Datei per Doppelklick, dann schließt sich das Programmfenster schneller als man die Ausgabe lesen kann.)

[Bilder: Zum Betrachten bitte den Artikel aufrufen.]

Es sei an dieser Stelle nochmal klargestellt, dass die beiden genannten Tools selbst keine Sicherheitslücken schließen, sondern lediglich Informationen darüber ausgeben, welche Gegenmaßnahmen auf dem Windows-System aktiv sind.

Leistungseinbußen durch Spectre-Gegenmaßnahmen
Allerersten auf Reddit veröffentlichten Benchmarks des Nutzers „Perseiii“ zu Folge hat der in Form eines BIOS-Updates bereitgestellte neue Microcode für Intel-CPUs (also die Maßnahme gegen Spectre „Variant 2“) in einzelnen Benchmarks deutliche Leistungseinbußen zur Folge – zumindest deutlichere als die Meltdown-Gegenmaßnahmen in Form des Windows-Updates.

[Bilder: Zum Betrachten bitte den Artikel aufrufen.]

Darüber hinaus hat derselbe Nutzer auch Benchmarks von „Rise of the Tomb Raider“ gemacht und dort keine Leistungseinbußen bei den durchschnittlichen FPS festgestellt. Zwar sind die Min-FPS eingebrochen, das aber nur sehr kurz ganz am Anfang des Benchmarks, also noch halb im Ladevorgang.

Inwiefern diese Ergebnisse, sollten sie denn reproduzierbar sein, auf AMD-CPUs übertragbar sind, ist noch unklar. Auch AMD hat mit dem Ausliefern von Microcode-Updates begonnen, um das auf AMD-CPUs angebliche „Near-Zero Risk“ durch Spectre „Variant 2“ anzugehen.

Update-Empfehlung
ComputerBase wird nächste Woche eigene Benchmarks durchführen. Bis dahin sei jedem Windows-Nutzer geraten, zumindest das Windows-Update – das unter anderem die Maßnahmen gegen Meltdown („Variant 3“) und erste Spectre-Patches für Edge und Internet Explorer enthält – aus Sicherheitsgründen zeitnah zu installieren. Denn jenes hat, von einzelnen Micro-Benchmarks abgesehen, nach jetzigem Stand der Dinge in Spielen und Desktop-Anwendungen keine messbaren oder vernachlässigbare Auswirkungen auf die Performance – und auf AMD-CPUs werden die Meltdown-Gegenmaßnahmen laut PowerShell-Script gar nicht scharf geschaltet. Auf Intel-CPUs kann der enthaltene Meltdown-Workaround laut Microsoft, sollte es wirklich Probleme geben, mittels der folgenden beiden Befehle gefolgt von einem Reboot jederzeit wieder deaktiviert werden:

Code:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Falls man sich umentscheidet und den deaktivierten Meltdown-Workaround wieder aktivieren möchte, dann geht das wie folgt:

Code:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Auch zur Verfügung stehende Browser-Updates – beispielsweise Firefox 57.0.4 (Download) – sollte man schnellstmöglich installieren. Chrome-Nutzer können das mit Chrome 64 standardmäßig kommende Feature Strict Site Isolation auf der Seite „chrome://flags/#enable-site-per-process“ auch schon in Chrome 63 aktivieren.

Raspberry Pi nicht betroffen
Einer Stellungnahme der Raspberry Pi Foundation zu Folge ist kein Raspberry Pi von Meltdown oder Spectre betroffen, weil die verbauten Chips ARM1176, Cortex-A7 und Cortex-A53 es nicht sind. Diese Aussage deckt sich mit der vorgestern veröffentlichten Stellungnahme von ARM.

Raspberry Pi Foundation schrieb:
Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use.

[...]

The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort.

Ehemaliger Intel-Mitarbeiter dämpft Hoffnung auf kurzfristige Hardware-Fixes
Unterdessen hat der ehemalige Intel-Mitarbeiter Joe Fitz in einer Tweet-Serie dargelegt, weshalb man nicht damit rechnen solle, dass schon in den nächsten Monaten neue CPUs ohne die Hardware-Bugs veröffentlicht würden. Jeder „Build“ (bei Hardware „Stepping“ genannt) koste mehrere Millionen Dollar, dauere mehrere Monate und die machbaren Änderungen seien aufgrund möglicher Nebenwirkungen – auch physikalischer Natur – stark eingeschränkt. Es lohnt sich, die komplette Tweet-Serie zu lesen.

[Embed: Zum Betrachten bitte den Artikel aufrufen.]
 
Zurück
Oben