Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht Server-Benchmarks)

Was hat Dein entpacktes BIOS für eine Dateiendung? Konntest Du der fertig gepachten BIOS.bin Deine Endung verpassen (siehe in meinem Guide am Schluss)? Wenn ja, wie?

*.bin. Das Ubu Tool bietet am Ende (Nach Deinem letzten Screenshot nach "drücken Sie eine beliebige Taste") bei mir die Option, die Datei umzubennen.
delme.jpg

Oder eben im Windows. (Die Windows Settings wirst Du gemacht haben oder? [Guide] BIOS mit uCodes patchen (Meltdown und Spectre)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wo siehst du dort bitte, dass da Zahlen im Gegensatz zu AMD stehen??? -> steht nichts vom im Link
Und wo siehst du dort, dass da nur noch halb so viele Daten kopiert! werden? -> steht auch nichts von im Link

AMD -> Ich sehe zwischen dem Pinken (ungefixt) und dem grauen (AMD-Retpoline) Balken so gut wie keinen Performanceunterschied, außer für den Threadripper 1950X im "Flexible IO"-Test
Intel -> Ich sehe durch den Intel-Retpoline-Fix (hellgrün) gegenüber dem Kernel ohne Fix (blau) in einigen Benchmarks ca. 10% Leistungsverlust, und beim Kopieren von Dateien sogar ca. 40% (wie 50% sah es aus, als ich beim Aussteigen aus der U-Bahn hektisch noch den Beitrag von oben abgesendet habe)

Edit: Man sieht hier auch, dass AMD und Intel-CPUs jeweils verschiedene Patches brauchen - bei AMD reicht ein "Minimal-Retpoline" offensichtlich aus, während Intel das Vollprogramm braucht, und Intel Kaby- und Skylake-CPUs zusätzlich noch RETPOLINE_UNDERFLOW.
 
Zuletzt bearbeitet:
Ich habe jetzt den Microcode 3B mittels VMWare Tool geladen.

Mit Microcode #38
PS davor 38.jpg

Mit Microcode #3B
PS danach 3B.jpg

Wie darf man das Ergebnis interpretieren? Funktioniert das Microcode Update für Spectre?

InSpectre meldet, dass ich gegen Meltdown geschützt bin, obwohl kein KB4056892 installiert ist. Keine Ahnung warum...

Für 1703 ist es ja auch die KB4056891... *Imbodenversink*

@AliManali Ich habe die BIN-Datei einfach per Explorer umbenannt. Der Originalname war X99XK3.10.
 
Zuletzt bearbeitet:
Es ist Wochenende und (je nach wie man will) spät (oder früh) am Abend , daher sorry, falls ich etwas nicht blicke. Aber Deine Antwort enhält einige Wiedersprüche. Vermutlich meintest Du mit "Und das innerhalb der VM" eher "von der VM hraus". Ja der Hypervisor ist auf dem Host auch nur ein Programm. Aber nach meinem Verständnis, auf Grund der Technik, dennoch vom Host isoliert. Ich verstehe, worauf hinaus willst.

Ja, du hast recht, die beiden Sätze sind nicht richtig... Sie hätten lauten sollen: "Nicht also nur IN der VM, sondern potentiell im kompletten Userspace des Hosts... Und das von innerhalb der VM herraus"
-> sollte meinen, du hast potentiell die Möglichkeit, aus der VM auszubrechen - da der Spaß IN der VM auch nur im Userspace läuft.

Konkret in Produkten, du kannst mit Typ 1 oder 2 Hypervisor bspw. relativ sicher gehen, dass du aus einer VM nicht auf den Kernelspace des Hosts und auch nicht auf den den Kernelspace der VMs kommst. Weil das ganze in Hardware gelöst wird.
Bei einer Software-Virtualisierung, bspw. einem Emulator oder bei der Arbeit mit virtuellen CPUs ist das hingegen wiederum potentiell sogar möglich. Da hier der Hardwareschutzt nicht greift und auch der Meltdown fix nicht hilft. Letzteres zumindest nicht um zwischen den VMs zu schützen. VM 1 hätte potentiell Zugriff auf VM 2 Kernelspace via Spectre an dem Punkt, wo die Daten in den Speicher geladen wurden.

Am Ende lässt sich das aber eher schwer beschreiben, da so oder so konkret gewusst werden muss, was für Daten da wo stehen um was abgreifen zu können. Der Spaß setzt auf spekulative Ausführung von Code - gefolgt von Zeitmessungen für den Zugriff. Es ist alles weit entfernt von einem simplen Laden einer Speicheradresse... Der Aufwand ist ziemlich enorm.

Aber die Antwort lasse ich so nicht gelten. Ich sehe den Userspace der VM von dem des Host isoliert, daher greift Spectre imo nicht vom Userspace der VM auf den Userspace des Host. Anderenfalls, bitte um valide Erklärung.

Nein, Spectre macht keinen Unterschied um welchen Speicher es sich handelt. Du kannst via Spectre nicht vom Userspace auf den Kernelspace zugreifen, denn das wäre dann Meltdown - Kernalspace Access. Spectre heist Userspace. Welche Daten ist dabei nicht entscheidend. Nur eben nicht Kernelspace. Und damit potentiell aus der VM herraus auf einen Datenbestand vom Host (oder auch einer anderen VM)
Problem dabei nur (was das ganze so unwahrscheinlich macht - vor allem mit VMs), als Angreifer musst du ziemlich genau wissen, wo die Daten stehen. Und der Angriff ist noch dazu recht lahm. Also mal so eben auf die Schnelle alles auslesen ist nicht... Wahrscheinlich hat sich über die Zeit der Bestand schon geändert und du bekommst da gar nichts verwertbares raus.

Das PoC bis jetzt zeigte ja bspw. Zugriffe auf Passwörter im Browser gespeichert - was vergleichbar einfach zu erreichen ist. Da du vor allem bei OpenSource Geschichten oder durch Analyse der Software auch ohne Quellcode da an Infos kommst. Wer den Code versteht weis genau was das Ding macht... Und kann entsprechend angreifen. Wie eben der Dieb, der genau weis, wann du zur Arbeit gehst früh und nicht einfach auf gut glück mal klopfen geht ob da vllt niemand Zuhause ist. letzteres wäre, wenn du versuchen würdest aus der VM herraus auf andere Speicherbereiche zuzugreifen. (VM übergreifend/Userspace des Hosts) :wink:

Aber egal, gegen Meltdown brauchst du keine VM - weil die Meltdown-Fixes auf Hostebene dies schon verhindern. Gegen Spectre hilft dir die VM auch nur bedingt - sie machts potentiell vielleicht wieder unwahrscheinlicher, lösbar ist das aber so nicht. Wie auch native auf dem Blech nicht...

Es gibt nicht den Bug, sondern 4 Bugs 1=Meltdown, 2 bis 4 = die 3 Spectre Varianten. Du beziehst Dich auf 1 und der ist durch ein OS Update gefixt. Ich will nicht sagen, dass ich ggf. nicht unrecht habe. Aber das ist keine valide Antwort, um mich zu wiederlegen.

Wieso vier?
Es sind drei...
Spectre v1/Sectre v2 und "Spectre v3" aka Meltdown.
Man könnte sagen, Meltdown ist Spectre mit Kernelspace access. Die Idee dahinter ist nicht wirklich anders. Aber Zugriff auf höher priviligierte Speicherbereiche wird perse von der CPU normal verhindert. Bei eigentlich allen modernen Architekturen. Dummerweise lässt sich der Schutz bei Intel umgehen, da die Zugirffsverletztung zu spät auslöst und man vorher schon Daten abfingern kann.
Spectre wirft aber keine Verletzung. Spekulative Codeausführung wirft diese so nicht. Getätigt werden die Ausführungen aber halt trotzdem - und durch Zeitmessungen bekommt man das auch abgefingert wie belegt wurde.

AMD -> Ich sehe zwischen dem Pinken (ungefixt) und dem grauen (AMD-Retpoline) Balken so gut wie keinen Performanceunterschied, außer für den Threadripper 1950X im "Flexible IO"-Test
Intel -> Ich sehe durch den Intel-Retpoline-Fix (hellgrün) gegenüber dem Kernel ohne Fix (blau) in einigen Benchmarks ca. 10% Leistungsverlust, und beim Kopieren von Dateien sogar ca. 40% (wie 50% sah es aus, als ich beim Aussteigen aus der U-Bahn hektisch noch den Beitrag von oben abgesendet habe)

Edit: Man sieht hier auch, dass AMD und Intel-CPUs jeweils verschiedene Patches brauchen - bei AMD reicht ein "Minimal-Retpoline" offensichtlich aus, während Intel das Vollprogramm braucht, und Intel Kaby- und Skylake-CPUs zusätzlich noch RETPOLINE_UNDERFLOW.

Du hast meine Fragen nicht verstanden... Du verlinkst nen Artikel wo der AMD Wert überhaupt nicht drin ist. (das war Frage 1)
Und du erzählst von nur halb so viel Kopierspeed bei Frage 2, obwohl das überhaupt nicht gemessen wurde in dem Artikel.
Schau dir doch bitte einfach mal an, was der FS-Mark Wert überhaupt ist...
 
Für Nutzer des 1150 Sockels scheint es zumindest bei MSI noch Hoffnung zu geben. Sowohl für z87, als auch für z97 Boards kursieren bereits erste BETA-BIOS-Versionen, die von MSI an Personen herausgegeben wurden, die beim Support gefragt haben https://forum-en.msi.com/index.php?topic=298434.0;prev_next=next#new. Ich hatte eigentlich vor, mein BIOS jetzt am WE selber zu modden, da sich der Aufwand dafür imho in Grenzen hält. Jetzt warte ich allerdings noch ein paar Tage, da mir eine offizielle Lösung lieber ist.
 
Nein, Spectre macht keinen Unterschied um welchen Speicher es sich handelt. Du kannst via Spectre nicht vom Userspace auf den Kernelspace zugreifen, denn das wäre dann Meltdown - Kernalspace Access. Spectre heist Userspace. Welche Daten ist dabei nicht entscheidend. Nur eben nicht Kernelspace. Und damit potentiell aus der VM herraus auf einen Datenbestand vom Host (oder auch einer anderen VM)
Problem dabei nur (was das ganze so unwahrscheinlich macht - vor allem mit VMs), als Angreifer musst du ziemlich genau wissen, wo die Daten stehen. Und der Angriff ist noch dazu recht lahm. Also mal so eben auf die Schnelle alles auslesen ist nicht... Wahrscheinlich hat sich über die Zeit der Bestand schon geändert und du bekommst da gar nichts verwertbares raus.

Danke Dir für die ausführliche Antwort, ja Du hast Recht, das leuchtet mir jetzt ein. Es sind alle Informationen enthalten, daher will ich jetzt nicht lange lamentieren.


Wieso vier?
Es sind drei...
Spectre v1/Sectre v2 und "Spectre v3" aka Meltdown.

Stimmt auch wieder, Meldown ist ja CVE-2017-5754 [Rogue Data Cache Load]
.


Ich habe jetzt den Microcode 3B mittels VMWare Tool geladen.

Mit Microcode #38
Anhang anzeigen 424980

Mit Microcode #3B
Anhang anzeigen 424981

Wie darf man das Ergebnis interpretieren? Funktioniert das Microcode Update für Spectre?


Mit Microcode 38 bekommst Du Hardware support for branch target injection mitigation is present: False
Das bedeutet, der Microcode ist nicht gegen Spectre gepatched.
Mit Microcode 3B bekommst Du Hardware support for branch target injection mitigation is present: True
Das bedeutet, der Microcode ist gegen Spectre gepatched.

Da bei der VMware Methode der Microcode zu spät geladen wird, hasst Du aber folgendes Problem:
Windows OS support for branch target injection mitigation is enabled: False

Würdest Du flashen, stünde dieser auf True.

Mehr Info hier: Windows: How to get latest CPU microcode without modding the BIOS | Page 4 | guru3D Forums

Das hier bezieht sich auf Meldown und ist durch das OS Update gefixt:
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: True [not required for security]


ihr habt doch hier euren microcode thread
[Guide] BIOS mit uCodes patchen (Meltdown und Spectre)

wieso müsst ihr den müll hier auch noch posten?
es gibt nichts dämlicheres wenn noobs ihre CPUs mit irgendwelchen komischen codes und programmen flashen wollen, verschont uns bitte damit....

Das Flashen der Microcodes steht in direktem Zusammenhang mit der Thread Thematik. Also ist daher kein OT.
Und ist, für viele evtl. die einzige Möglichkeit, sich halbwegs vor Spectre zu schützen (Wenn MS die Microcodes nicht ausliefert und die Motherboard Hersteller für ältere Produkte keine Patche liefern).
Das wird sich zeigen aber es kann nicht schaden, sich dahin gehend zu informieren.

Von jemandem der hier schon so lange dabei ist (übrigens auch nur 3 Jahre mehr als ich...), hätte ich daher ein etwas reflektierteres und weniger ausfallendes Verhalten erwartet.
 
Zuletzt bearbeitet:
Es gibt nicht den Bug, sondern 4 Bugs 1=Meltdown, 2 bis 4 = die 3 Spectre Varianten. Du beziehst Dich auf 1 und der ist durch ein OS Update gefixt.
Es gibt bisher 3 bekannte Exploit's:
1. CVE-2017-5753
2. CVE-2017-5715
3. CVE-2017-5754

Welche sind dir noch bekannt?
1 und 2 sind Spectre, 3 ist Meltdown.
 
Um das vielleicht noch mal anzumerken, die Angriffe können über Sandbox-Systeme (VM) hinweg erfolgen, die Virtualisierung schützt davor nicht.
Das ist schon seit Seite 1 bekannt.

Wichtig ist, dass Meltdown das schwerwiegende Problem ist, da Speicherzugriffe danach mit 500KB/s lesend erfolgen können. Bei den klassischen Spectre-Angriffen wurden bislang maximal 10KB/s erreicht. Also frohes Scannen für die Angreifer. Und jetzt frage ich mich, wieso hier so viele Otto-Normal-Zocker sich so einen Kopf machen. :d
 
Mit den 10 KB/s hast Du schon recht. Aber um ein anderes Beispiel zu nennen: Beim Umgang mit persönlichen Daten im Netz ist die heutige Generation eher locker. Meiner Generation (Baujahr 79 - oder zumindest mir) wurde noch eingetrichtert:
Auch wenn Ihr heute denkt, mit den Daten kann keiner etwas anfangen, Ihr wisst nicht was morgen möglich ist. Genau so war es in Bezug auf Security.

Das Du auf die Thematik mit den 10 KB/s hinweist und aus technischer Sicht relativierst, ist ja richtig. Aber aus meiner Sicht, sollten man den Leuten auch nicht suggerieren, dass sie sich dafür rechtfertigen müßen, Ihre Systeme absichern zu wollen.
Amen *g*
 
Merkst Du was irgendwas von verringerter Performance weil auf dem Papier sind die Zahlen krass....
 
VMs fühlen sich etwas langsamer an. Im Host OS merkt man nichts.
Bei Battlefield 1 ist es schwer zu sagen, das laggt ja hier und da immer wieder im Multiplayer. Die FPS sind laut Afterburner aber gleichgeblieben.

P.S. Die VMs liegen auf einer 500 GB Samsung 850 EVO SSD.
 
Zuletzt bearbeitet:
Ich habe den 23ger Microcode für meinen Haswell 4970K (Z87 Board) über die USB Stick Methode eingespielt. [Guide] BIOS mit uCodes patchen (Meltdown und Spectre) - Seite 2

1.5 Stunden Battlefield 1 ohne Probleme.
SSD Performance (Samsung SSD 840 pro 256 GB:

vorher:
Anhang anzeigen 425149
nachher:
Anhang anzeigen 425150

die SSD ist hart eingebrochen beim sequentiellen Schreiben:sick: ... Der Rest geht ja...

Hier nochmal offiziel bestätigt, dass von ASrock doch Bios updates für X99 kommen wird:

ASRock---New BIOS for Intel SA-00088 security update

"New BIOS versions for ASRock 8/9/X99 series and SoC motherboards will be created after new intel microcode is available"
 
Zuletzt bearbeitet:
Ja auf den Artikel bin ich am Samstag auch schon gekommen,
Ich zitiere mich mal selber:
"So nach dem Motto, grosse Firmen und der Staat missbrauchen das Netz – und diese interessieren sich jetzt für die Lösung, die das verhindern soll? Kommt das nur mir seltsam vor? Prinzipiell klingt das Verfahren einleuchtend, aber mit guter Verschlüsselung erreicht man dasselbe heute doch bereits? Wenn gut verschlüsselte Datenpakete "umgeleitet" oder kopiert werden, nützt das ohne Schlüssel noch nicht viel. Deshalb interessieren sich Abhörer für die Kontakte selbst, die sie mit SCION auch verfolgen können, oder?"
 
Zuletzt bearbeitet:
die SSD ist hart eingebrochen beim sequentiellen Schreiben:sick: ... Der Rest geht ja...

Also bei Windows VMs merkt man schon ziemlich einen Unterschied. Da ich auf der VM (Eval Windows) nichts groß drauf habe, habe ich einfach mal Firefox aufgemacht und 10 unterschiedliche Youtube Videos laufen lassen.
Mit dem neuen Microcode stottert die Wiedergabe deutlich im vergleich zum alten (Mit den USB Stick kann ich ja fix wechseln). Auf dem Host (Windows) habe ich das Problem nicht.

Ich wollte es dann genauer wissen und habe den SSD Benchmarkt in der VM laufen lassen. Hier sind die Unterschiede analog zum Host.
Der Microcode scheint sich bei VMs also nicht nur auf das IO Verhalten auszuwirken.

Hypervisor ist VMware Workstation 11 (Habe ich mal zu einer Zertifizierung dazu bekommen, falls fdsonne das mitliest, könnte es peinlich für mich werden. *g* Zu meiner Verteitigung: Security war nicht so Prüfungsthema, eher Storage, Netz etc. und ich habe auch eher VMs betreut und nicht die Hosts.) Ich habe noch einen ESXi Server im Multiboot aber der läuft gerade nicht, ich habe nächste Woche auch keine Zeit das zu testen.
 
Zuletzt bearbeitet:
Ist ja auch nur logisch. Virtuelle Maschinen leben von Syscalls, also dem Problembereich. Dass die Auswirkungen so krass sind, überrascht mich aber.

Die VMware Workstation läuft ja bei mir auf einem Windows mit einem Haswell. Rechezentren düften eher auf ESX Server (Unix Derivat) plus aktuelle CPU setzen (4 Jahre Hardware Abschreibung). Da wird es ggf. anders aussehen.
Wobei die Konstellation: Haswell, Windows, VMware Workstation wohl in einigen kleineren mittelständischen Unternehmen zu finden sein sollte.

Das mit den Syscalls google ich mal, morgen...
 
Brauche ich bei meinem Dell 17R SE wohl nicht mehr rechnen mit Bios Update
 
Die meisten brauchen nicht mehr auf BIOS-Updates zu hoffen. Die einzigen, die wirklich hinterher sind, wären Anbieter von Serverplatinen. Supermicro bspw. scheint sich echt Mühe zu geben - wenn die ganzen BIOSe kommen, die angekündigt wurden.

Otto-Normal muss selbst Hand anlegen.
 
Die meisten brauchen nicht mehr auf BIOS-Updates zu hoffen. Die einzigen, die wirklich hinterher sind, wären Anbieter von Serverplatinen. Supermicro bspw. scheint sich echt Mühe zu geben - wenn die ganzen BIOSe kommen, die angekündigt wurden.

Otto-Normal muss selbst Hand anlegen.

Warum, die Entwicklung neuer Biose ist doch noch im Gange und noch nicht abgeschlossen, ich warte ja immer noch auf Haswell Updates ....
 
Die meisten brauchen nicht mehr auf BIOS-Updates zu hoffen. Die einzigen, die wirklich hinterher sind, wären Anbieter von Serverplatinen. Supermicro bspw. scheint sich echt Mühe zu geben - wenn die ganzen BIOSe kommen, die angekündigt wurden.

Otto-Normal muss selbst Hand anlegen.

Hier zumindest wird für x99, dass 4 Jahre alt ist, zugesichert, offiziell, dass updates kommen, die Partner aber auf den fehlerbereinigten Microcode warten:

Hier nochmal offiziel bestätigt, dass von ASrock doch Bios updates für X99 kommen wird:

ASRock---New BIOS for Intel SA-00088 security update

"New BIOS versions for ASRock 8/9/X99 series and SoC motherboards will be created after new intel microcode is available"

Das entpricht auch der Meldung von Intel, dass die Partner angewiesen wurden, erstmal die updates einzufrieren, bis der neue Code rausgegeben wurde. Thema reboot Problematik.
 
Ich hab hier einen HP EliteDesk, Bios Update vorhanden, eingespielt, kein Booten mehr möglich^^ (ja Bootreihenfolge, AHCI usw. alles gecheckt, keine Chance)
 
Ich hab hier einen HP EliteDesk, Bios Update vorhanden, eingespielt, kein Booten mehr möglich^^ (ja Bootreihenfolge, AHCI usw. alles gecheckt, keine Chance)

Sollte das ein Bios File von der HP Support Seite gewesen sein für dieses Gerät, wäre das wirklich erschreckend, geht ein zurück Flashen noch?

Ansonsten würde noch eine Win Neuinstallation in Frage kommen ...
 
Nein, steht ausdrücklich dabei, zurück flashen nicht möglich^^

Bin grade beim neu installieren, was anderes half leider nicht.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh