Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren

[MadPenguin]

Da werden nicht die GPUs gepatcht, sondern die Software/Treiber, damit man nicht/schwerer die CPUs angreifen kann.

Aus deinem eigenen Link:

Ich schwöre, beim Posten war das Update noch nicht da -.-. sorry trotzdem. LG

[anddill]

Das Thema hatten wir ab hier schon mal:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11598022#post11598022

[StefanV]

Wurde das schon gepostet?
https://www.youtube.com/watch?time_continue=1&v=LC1WuKdPVCQ

In Witcher 3 gibt es bis zu -16% Leistung nach dem Windows-/ und Biospatch mit einem i5-8400. Das ist nicht gerade wenig.
hmm andere sagen, es kostet quasi nichts
komisch
Ja, weil das ausgiebig streamt und dadurch mehr Syscalls verwendet werden.
Das kann unter umständen in einigen sehr streamingintensiven Games richtig übelst werden...

Gucke einfach das ganze Video. ;) Es bleibt so wie es schon immer war: Man kann nicht "X % langsamer" auf das Thema drücken. Man muss von CPU zu CPU und von Software zu Software unterscheiden.
...und genau deswegen sollte man noch mit einem Kauf von Intel Zeugs warten und schauen, wie sich das ganze auf andere Programme auswirkt.

Interessant wären ev. noch DOOM (OGL + Vulkan) und Wolfenstein II.

[CompuJoe]

Ein Freund von mir Flucht gerade im Discord das bei FH3 die fps wenn er durch die Gegend fährt oft massiv einbrechen, was er vor dem Patch nicht hatte.
Hat nen Ivy i5 und eine R9 290

Ich hatte heute einen BS mit Memory Management, hatte ich vor dem Patch noch nie

[StefanV]

Ein Freund von mir Flucht gerade im Discord das bei FH3 die fps wenn er durch die Gegend fährt oft massiv einbrechen, was er vor dem Patch nicht hatte.
Kann das wer nachprüfen??
Wäre interessant näheres darüber zu erfahren.

[gravitationsfeld]

Interessant wären ev. noch DOOM (OGL + Vulkan) und Wolfenstein II.
Kann mir nicht vorstellen, dass es da nen Unterschied macht. Das Problem ist wenn man disk I/O nicht in separaten Threads hat.

[CompuJoe]

Geht weiter, seit dem Patch schmiert mir im FF laufend Twitch oder YT ab.

https://www2.pic-upload.de/thumb/34635571/tababs.jpg (https://www.pic-upload.de/view-34635571/tababs.jpg.html)

Ein aktualisieren des Tab reicht und läuft weiter, aber nervig wenn man gerade auf der Couch lümmelt.
Hatte ich auch vorher nicht!

[StefanV]

Kann mir nicht vorstellen, dass es da nen Unterschied macht. Das Problem ist wenn man disk I/O nicht in separaten Threads hat.
Kann das nicht bei 'ner 4Kern /4 THread CPU eng werden??

[BBig]

Einige Linuxer sind bei uns ja mit Arch unterwegs.

Von testing nach live:
https://www.archlinux.org/packages/extra/any/intel-ucode/

Dann tippert mal alle eure -Syus in die Konsole, :D

==//==

Ein Script von Ganon wurde ja schon gepostet:
Wer Linux benutzt: hier erstellt gerade jemand ein Skript, welches ähnlich nach den Anfälligkeiten prüft, wie das Skript von Microsoft für Windows:

https://github.com/speed47/spectre-meltdown-checker

[yummy_candy]

Kann jemand von euch verifizieren, inwiefern im letzten Windowspatch für Windows 10 schon neukompilierte Updates für windowseigene Programme enthalten waren?

[Loeschzwerg]

Offizielle Info zu den Systemen und Lösungen von Fujitsu:
http://support.ts.fujitsu.com/content/SideChannelAnalysisMethod.asp

[unl34shed]

Wurde das schon gepostet?
https://www.youtube.com/watch?time_continue=1&v=LC1WuKdPVCQ

In Witcher 3 gibt es bis zu -16% Leistung nach dem Windows-/ und Biospatch mit einem i5-8400. Das ist nicht gerade wenig.

Watch Dogs 2 soll wohl auch ordentlich verlieren. Hab ich gestern in einem Video gesehen, da ging es von 100Fps auf 87Fps Avg. 1%-low auch stark betroffen in dem Spiel.

(min. 3:00) https://www.youtube.com/watch?v=M2e9G5b2elI

[nimrod]

moin, ich bin jetzt nicht komplett im bilde, aber sehe ich das richtig, dass man aktuell davon ausgehen kann, dass ältere cpu-generationen kein microcode update erhalten und dadurch auch nicht mehr sicher sind, da ein alleiniges patchen des BS nicht ausreichend ist?

kann ein microcode update eigentlich nur via BIOS erfolgen? also ist man hier abhängig vom boardhersteller?

grüße.

[Zockerfrettchen]

Intel äußert sicht wieder:

https://www.bloomberg.com/news/articles/2018-01-11/intel-says-chip-security-fixes-leave-pcs-no-more-than-10-slower

Für Ottonormal-Verbraucher also bis zu 10%... Wie man das als nicht signifikant darstellen kann bleibt mir ein Rätsel. Zu Servern wird noch nichts gesagt, allein daran kann man sehen, wie stark die Performance beeinträchtigt sein wird. Insgesamt bleibt es eine Katastrophe, von der leider die Cpu-Hersteller am stärksten profitieren werden. Mann kann nur hoffen, das Intel für seine Kommunikationspolitik durch Serverbetrieber bestraft wird bzw. dass diese das Risiko, nur auf eine Architektur zu setzen, nicht wiederholen. Mehr Konkurrenz würde am Ende dem Konsumenten entgegen kommen. Dann hätte das Fiasko wenigstens irgendeinen positiven Effekt.

Grüße,
Zockerfrettchen

[Schnoesel]

kann ein microcode update eigentlich nur via BIOS erfolgen? also ist man hier abhängig vom boardhersteller?

Sieht so aus. den Microcode per Treiber einzuspielen bringt wohl nicht das gewünschte Ergebnis:

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Letzes Update:
Neuer Microcode per Treiber ist keine Lösung

"Kreative ComputerBase-Leser sind auf die Idee gekommen, in Ermangelung eines vom Mainboard- bzw. Notebook-Hersteller bereitgestellten BIOS- bzw. Firmware-Update die Angelegenheit selbst in die Hand zu nehmen und den neuen Microcode mit dem VMware CPU Microcode Update Driver einzuspielen. [...]"

[dargo]

Watch Dogs 2 soll wohl auch ordentlich verlieren. Hab ich gestern in einem Video gesehen, da ging es von 100Fps auf 87Fps Avg. 1%-low auch stark betroffen in dem Spiel.

(min. 3:00) https://www.youtube.com/watch?v=M2e9G5b2elI
Verhält sich ähnlich wie Witcher 3... bis zu -18% sehe ich da.

[Sven77]

Ich hab bei mir jetzt auch das Bios aufgespielt (Asus Z270F), zumindest in PUBG und Fortnite ist es absolut unauffällig, sehe keine Unterschiede zu vorher

[IceKillFX57]

Würde Mal vermuten daß es dennoch 5-10% sind aber die merkt man dann halt nicht. Ob man nun 70 oder 63 fps hat, wird man wohl nicht merken da es eben kein Benchmark gibt der das 1:1 abspielt.
Dann aber wohl bei 20% in extrem Situationen ausmacht.

Lustig finde ich jedoch das Intel sagt das 10% nicht nennenswert sind.
Bedeutet für mich das die ganzen Generationenswechsel es auch nicht sind xD
Diese brachten ja im Grunde auch von einer zur nächsten gerade Mal 8%-10%.

[Birdman]

Verhält sich ähnlich wie Witcher 3... bis zu -18% sehe ich da.
Aktuell deutet ja einiges darauf hin, dass neuere Intel CPUs stärker verlieren.
Ich interpretiere das zur Zeit so, dass hier ein Teil der IPC Steigerungen der letzten paar Core µArchs durch die Software und Microcode Anpassungen wieder negiert werden.

Ich weiss dass für alte CPUs aktuell noch kein Microcode Update zur Verfügung steht und entsprechende Benchmarks daher mit Vorsicht zu geniessen sind.
Dort wo dies aber bereits der Fall ist, verliert man die meiste Performance durch die Software Patches und das Firmware Upgrade scheint dann nur noch wenig auszumachen. (allerdings möglich, dass es bei älteren CPUs dann genau umgekehrt ist.)


Auf jedenfall sind die 10% recht heftig, vor allem da es in Cornercases wohl noch deutlich mehr sein wird. Vor allem psychologisch tut das dann schon sehr weh...

[Sven77]

Würde Mal vermuten daß es dennoch 5-10% sind aber die merkt man dann halt nicht. Ob man nun 70 oder 63 fps hat, wird man wohl nicht merken da es eben kein Benchmark gibt der das 1:1 abspielt.
Dann aber wohl bei 20% in extrem Situationen ausmacht..

Würde ich merken da PUBG bei 144fps dicht macht und man öfters Drops hätte als sonst, dasselbe bei Fortnite das ich auf 120fps limitiert habe. 10% würden da definitiv auffallen. Auf der anderen Seite weiss ich nicht wie streaminglastig diese Games sind. CPU ist Kaby-Lake 7700K @ stock

[IceKillFX57]

Kann es sein das das ganze auch vom RAM abhängig ist?

[Gorkon]

Verhält sich ähnlich wie Witcher 3... bis zu -18% sehe ich da.
Die "-18%" stehen aber auf der linken Seite zur Debatte == Pre-Update == VOR dem Patch. Die Leistung wird also durch den Meltdown / Spectre-Patch besser...

:confused:

[dargo]

Ich denke die Beschriftung im Video ist vertauscht, ansonsten wäre das etwas strange. :D

[labecula]

Würde Mal vermuten daß es dennoch 5-10% sind aber die merkt man dann halt nicht. Ob man nun 70 oder 63 fps hat, wird man wohl nicht merken da es eben kein Benchmark gibt der das 1:1 abspielt.
Dann aber wohl bei 20% in extrem Situationen ausmacht.

Lustig finde ich jedoch das Intel sagt das 10% nicht nennenswert sind.
Bedeutet für mich das die ganzen Generationenswechsel es auch nicht sind xD
Diese brachten ja im Grunde auch von einer zur nächsten gerade Mal 8%-10%.

Zum Glück rennt meine krüppelige 1050Ti eher ins Limit als alles andere an meinem älteren Sandy i7 System. Mit meiner vorigen 1080 wäre das sicherlich signifikant merkbar gewesen. Spiele gelegentlich Escape from Tarkov. Da rennt mir die Graka auch zu 100% ins Limit. Einem Bekannten allerdings mit einer 1080Ti kommt bei der gleichen Auflösung theoretisch nicht ins Limit und da bremst dann der Rest des Systems. Und er beschwert sich nun über merkliche FPS Einbrüche in großen Maps die sehr viel RAM benötigen (16 GB RaM sind quasi Vorraussetzung für das Spiel und werden auch genutzt). Sein System kommt kaum über die 60fps hinaus. Selbst bei mir komme ich bei Gleichen Einstellungen auf immerhin noch 40fps. Ich vermute das das Spiel quasi auch Streaming betreibt aber eben aus dem RAM heraus und nicht von HDD/SSD. eine reltiv neue i7 steht ihm zur Seite. Mein erster gedanke ging gleich Richtung der aktuellen Patches.

[HOT]

Watch Dogs 2 soll wohl auch ordentlich verlieren. Hab ich gestern in einem Video gesehen, da ging es von 100Fps auf 87Fps Avg. 1%-low auch stark betroffen in dem Spiel.

(min. 3:00) https://www.youtube.com/watch?v=M2e9G5b2elI
Na das kann ja lustige Ergebnisse geben gegen PinncleRidge :freak:. AMD tat gut daran das Teil auf April zu setzen, bis dahin sind alle BIOS-Update raus und man steht gegen Coffeelake mit Handbremse da. Da haben sich offenbar einige doch zu früh gefreut mit dem Windows Patch.

[Zockerfrettchen]

Aus meiner Sicht ist der eigentliche Skandal nicht die Sicherheitslücke in der Hardware. Ich denke bzw. hoffe, das Intel die Folgen in Form von Verlust von Marktanteilen zu spüren bekommt. Es sind ja auch andere Unternehmen betroffen, Sicherheitslücken wird es immer wieder geben, und je nachdem welcher Hersteller am besten der Sicherheit vorgebeugt hat, wird davon profitieren. Ich finde die Kommunikationspolitik von Intel absolut untragbar. Erst gab es kein relevantes Problem, dann wurden andere Hersteller durch ungenaue Aussagen diffammiert. Dann werden die Leistungseinbußen als nicht spürbar verkauft. Ist der Konsument also zu blöd, um es zu merken? Nach und nach kommt raus, das Server massiv unter den Patches leiden. Und den Konsumenten versucht man für dumm zu verkaufen, bis zu 10% wäre nicht signifikant. Die Jungs bei Intel haben zum Großteil Statistikvorlesungen besucht. Die sollten das besser wissen bzw. auch einschätzen können, dass dies auch der Konsument weiß. Dazu noch die Aktienverkäufe des CEO. Mir kommt die nächsten Jahre keine Intel CPU mehr ins Haus, es ist unter aller Sau. So und jetzt genug der Hasstirade ;-)

Grüße,
Zockerfrettchen

[Noebbie]

Hat jemand von euch ein Statement von Gigabyte zu dem Thema? Ich finde dazu nichts.

Ich habe das Gefühl, dass während man bei ASUS schon patched, bei Gigabyte noch lange geschwiegen wird. Das ärgert mich echt ein wenig und das könnte meine zukünftigen Kaufentscheidungen dann wohl auch beeinflussen!

[grizu]

Gibt es schon Sammelklagen ? würde sofort unterschreiben ..

[Mr.Freemind]

Es gibt gute Nachrichten für alle Besitzer eines Asus-Mainboards der 9er-Serie und auch X79. Asus hat uns soeben mitgeteilt, dass auch für Mainboards mit diesen Serien Spectre-BIOS-Updates erscheinen werden. Bereits in Kürze sollen erste Betaversionen verfügbar sein. Bis dahin sollen aber erst die Arbeiten an den Mainboards mit 100er-Serie aufwärts abgeschlossen werden.

:up:

PCGH (http://www.pcgameshardware.de/Mainboard-Hardware-154107/News/Spectre-BIOS-Updates-1247555/)

[Birdman]

Hier mal ein CPU Performancegraph von einem etwas älteren ESXi 6.5 Server (mit zwei Xeon E5-2660, SandyBridge Prozessoren) bei uns.
Da drauf laufen 15 Windows und Linux VirtualMachines, leider aber erzeugen die etwas zu wenig Last, als dass man hier nun wirklich einen Unterschied sehen würde.
Zudem gehe ich nicht davon aus dass hier schon eine CPU Microcode Mitigation aktiv ist, obwohl der hierzu gestern erschienene ESXi Patch bereits eingespielt wurde. (da gabs imho nur Updates für neuere CPUs)

https://dexter.birdman.ch/screens/misc/esxi_meltdown-spectre.png

[sapito]

deutliche Einbrüche scheint es auf SSD Systemen zu geben

c't hat ebenfalls bereits starke Einbrüche bei der SSD-Leistung nach dem Einspielen von BIOS- und Sicherheits-Updates feststellen können (Core i7-8700K, Asus Maximus X Hero, Samsung 960 Pro, zufällige Zugriffe mit 4K-Blöcken und 32 I/O-Targets). Die Samsung-SSD erreichte nur noch 105.986 I/Ops beim Lesen und 79.313 I/Ops beim Schreiben im Vergleich zu 197.525/185.620 I/OPs (vorheriges BIOS, Windows mit KB4054517).

https://www.heise.de/newsticker/meldung/Intel-Benchmarks-zu-Meltdown-Spectre-Performance-sackt-um-bis-zu-10-Prozent-ab-SSD-I-O-deutlich-mehr-3938747.html

das nenn ich aber mal heftig, hier werden die werte mehr als halbiert :eek:

[grizu]

Hier mal ein CPU Performancegraph von einem etwas älteren ESXi 6.5 Server (mit zwei Xeon E5-2660, SandyBridge Prozessoren) bei uns.


Für Sandybridge Systeme soll es doch keine updates geben, hmm

[unl34shed]

Ich find erschreckend, wie viele den Patch wieder runterschmeißen, wegen 5% weniger Leistung... Und dann mit Begründungen kommen wie "ist die letzten 10 Jahre ja auch nichts passiert"

Gut Intel hat die letzten Jahre gut an den 5% mehr Leistung ggü. dem Vorgänger verdient.

Bei so einem Verhalten wünscht man sich schon etwas, dass die Lücke ordentlich genutzt wird.

[4pple]

Watch Dogs 2 soll wohl auch ordentlich verlieren. Hab ich gestern in einem Video gesehen, da ging es von 100Fps auf 87Fps Avg. 1%-low auch stark betroffen in dem Spiel.

(min. 3:00) https://www.youtube.com/watch?v=M2e9G5b2elI
Autsch, danke für die Info. Wäre glatt an mir vorbeigegangen ohne dich.

[Birdman]

Für Sandybridge Systeme soll es doch keine updates geben, hmm
Gemäss SuperMicro sollte es irgendwann mal noch eines geben, es kanm aber sein dass Intel hier nach Server/Consumer CPUs unterschiedet und nur bei ersteren auch für ältere Generationen etwas anbieten will.
Ich gehe zudem davon aus, dass Intel sich quasi gezwungen sehen wird, auch für ältere Consumer Prozessoren noch Updates zu bringen, es sei denn es gibt wirklich technische Gründe, welche einen Fix auf Microcode Ebene verhindern.

[Exxtreme]

https://www.heise.de/newsticker/meldung/Spectre-Luecke-Auch-Server-mit-IBM-POWER-Fujitsu-SPARC-und-ARMv8-betroffen-3938749.html

Auch Sparc- und Ibm Power-CPUs sind offenbar betroffen.

[Rancor]

Ist bekannt wie Spectre ausgenutzt werden kann ? Also konkret? Was muss man dafür tun ?

[fp69]

Hat jemand von euch ein Statement von Gigabyte zu dem Thema? Ich finde dazu nichts.

Ich habe das Gefühl, dass während man bei ASUS schon patched, bei Gigabyte noch lange geschwiegen wird. Das ärgert mich echt ein wenig und das könnte meine zukünftigen Kaufentscheidungen dann wohl auch beeinflussen!

Einen Schnellschuss wirst du aber auch nicht wollen, oder?

[lumines]

Ich find erschreckend, wie viele den Patch wieder runterschmeißen, wegen 5% weniger Leistung... Und dann mit Begründungen kommen wie "ist die letzten 10 Jahre ja auch nichts passiert"

Ist eben das spontane Missverständnis, dass alle Lücken in Hard- und Software immer sofort bekannt sind (was übrigens niemals ein realistischer Zustand sein wird) und nur von verschiedenen Parteien zurückgehalten werden. Daraus wird dann geschlossen, dass 10 Jahre ja nichts passiert ist, obwohl die Lücke irgendwem bekannt gewesen sein muss (was natürlich nicht stimmt). Für viele ist schwer zu begreifen, dass extrem viele Lücken für alle Parteien bis zum Bekanntwerden durch eine kleine (oder große) Gruppe tatsächlich unbekannt sind.

Das liegt wahrscheinlich auch einfach daran, dass es für diesen Zustand keine einfache Analogie mit Brücken, Autos oder Häusern gibt. Welches Haus fängt schon an zu brennen, wenn irgendein ziemlich abstraktes Detail über die Bauweise bekannt wird und es jemand falsch anguckt?

[Complicated]

Es geht hier nur um v1.
Mit v1 kann ich aber nur auf Daten zugreifen für die der Prozess auch Zugriffsrechte hat. Wenn ich auf andere Daten zugreifen kann, dann ist das Meltdown (v3), nicht Spectre.
Jeden Tab in einen eigenen Prozess zu stecken löst das Problem offensichtlich.
Wenn man mit NoScript alle Skripte blockiert dann können die natürlich keinen schädlichen Code ausführen. Das gleiche kann man auch erreichen in dem man nie auf die Websites geht oder den Browser gar nicht startet.
Wenn ein Skript erstmal läuft dann kann es v1 ausführen, ABE hin oder her. ABE blockiert basierend auf der Herkunft des Skripts auf welche Daten es zugreifen und was es versenden darf.
Spectre BCP (v1) umgeht aber gerade bounds checks, also ist das völlig nutzlos. Das Skript wird niemals eine Anfrage senden um ein Passwort zu lesen und dann kann ABE auch nichts blockieren. Das Skript sucht sich die Speicheradresse und liest dann alles direkt aus.

NoScript/ABE können nur verhindern dass ein Skript ausgeführt wird, wenn es nicht whitelistet ist. Wenn es ausgeführt wird funktioniert v1.
Bei Site Isolation ist das egal. Das Skript läuft in einem eigenen Prozess und dort sind nur die eigenen Daten. V1 kommt nicht in andere Prozesse rein, also sind die sicher.
Deinen Ausführungen zu V3 und V2 waren soweit korrekt und decken sich mit meinen Ausführungen. Auch wenn Gipsel nach wie vor meint V2 wäre durch Site Isolation gefixt.

Das was ich nun zitiert habe entspricht ebenfalls dem was ich schrieb. Ich habe nicht geschrieben ABE schützt vor Spectre, ich schrieb, dass Site Isolation keinen zusätzlichen Schutz gegen V1 bietet der über das XSS von ABE hinaus geht. Über andere Exploits wurden im Kontext dieses Threads von mir keine Aussagen gemacht. Daher stimmen wir nur in einem Punkt nicht überein:
Bei Site Isolation ist das egal. Das Skript läuft in einem eigenen Prozess und dort sind nur die eigenen Daten. V1 kommt nicht in andere Prozesse rein, also sind die sicher.Das ist eben genau der Trugschluß und auch etwas das nicht einmal Google behauptet. Eine Mitigation ist kein Fix. Auch ist der Angriff in der branch prediction nicht aufzuhalten wenn eine andere Webseite in einem eigenen Prozess ihren Code (in diesem Fall den Angreifercode) ausführt. Der Weg um Daten aus dem TLB/Cache auszulesen bleibt erhalten, denn dort wird nach wie vor nicht unterschieden aus welchem Prozess die Sprungvorhersage stammt. Die im Voraus spekulierten Daten liegen dort im Puffer und können von jedem laufenden Prozess auf der CPU ausgelesen werden durch den Exploit.

Die Grundlage des Angriffs wird nicht verändert indem man die einzelnen Prozesse isoliert, solange sie alle die selbe branch prediction nutzen, wo diese Isolierung nicht statt findet. Genau das steht auch in der verlinkten Quelle bei github.

Mich würde mal interessieren wo ihr bei Google die Aussage lest Strict Site Isolation wäre ein Fix für V1 - die behaupten das interessanterweise nirgendwo. Mitigation!=Fix um das mal gleich vorwegzunehmen.
Hier steht es jedenfalls nicht drin:
https://www.chromium.org/Home/chromium-security/site-isolation
In addition to UXSS bugs, Site Isolation can also help to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html). Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.
Das ist keine Fix wie man lesen kann. Und es verhindert auch nicht das lesen aus "sonst nicht zugänglichen Daten innerhalb eines Prozesses", es erschwert das lediglich.

https://www.chromium.org/Home/chromium-security/ssca
Chrome allows users to enable an optional feature called Site Isolation which mitigates exploitation of these vulnerabilities. With Site Isolation enabled, the data exposed to speculative side-channel attacks are reduced as Chrome renders content for each open website in a separate process. Read more about Site Isolation (http://www.chromium.org/Home/chromium-security/site-isolation), including some known issues, and how to enable it via enterprise policies (https://support.google.com/chrome/a/answer/7581529) or via chrome://flags (https://support.google.com/chrome/answer/7623121).

Chrome's JavaScript engine, V8 (https://www.v8project.org/), will include mitigations (https://github.com/v8/v8/wiki/Untrusted-code-mitigations) starting with Chrome 64, which will be released on or around (https://www.chromium.org/developers/calendar) January 23rd 2018. Future Chrome releases will include additional mitigations and hardening measures which will further reduce the impact of this class of attack. Additionally, the SharedArrayBuffer feature is being disabled by default. The mitigations may incur a performance penalty.

Und all das hat den Exploit NOCH IMMER nicht gefixt. Wozu sollten sonst weitere Maßnahmen nötig sein am 23 Januar?

Also man sollte einfach nicht die falsche Information verbreiten "Strict Site Isolation" würde Spectre V1 fixen - dem ist einfach nicht so.

[lumines]

Mich würde mal interessieren wo ihr bei Google die Aussage lest Strict Site Isolation wäre ein Fix für V1 - die behaupten das interessanterweise nirgendwo. Mitigation!=Fix um das mal gleich vorwegzunehmen.
Hier steht es jedenfalls nicht drin:
https://www.chromium.org/Home/chromium-security/site-isolation

Das ist keine Fix wie man lesen kann. Und es verhindert auch nicht das lesen aus "sonst nicht zugänglichen Daten innerhalb eines Prozesses", es erschwert das lediglich.

https://www.chromium.org/Home/chromium-security/ssca

Und all das hat den Exploit NOCH IMMER nicht gefixt. Wozu sollten sonst weitere Maßnahmen nötig sein am 23 Januar?

Also man sollte einfach nicht die falsche Information verbreiten "Strict Site Isolation" würde Spectre V1 fixen - dem ist einfach nicht so.

Niemand hat hier von Strict Site Isolation als Fix geredet. Es erschwert die Ausnutzung nur stark. In meinem ersten Beitrag dazu habe ich nichts anderes geschrieben:

Panik sollte man nicht haben. Ich will hier jetzt auch nicht Chrome über den Klee loben, aber aktuell scheint es momentan der einzige Browser zu sein, der mit der Strict Site Isolation wirklich einen signifikanten Schutz gegen Spectre beim Surfen liefert.

Mildert natürlich alles nur ab, aber alle anderen Browser wurden davon ein bisschen überrannt, während Chrome das Problem mit einer einfachen Option stark abmildern kann. Das ist schon ein enormer Vorteil, der für die meisten Leute wahrscheinlich auch den meisten Nutzen hat.

Hier kann man übrigens mehr darüber lesen: https://www.chromium.org/Home/chromium-security/site-isolation

Das war die Ausgangsbasis für die restliche Diskussion und ich denke niemand hat später überhaupt davon angefangen, dass es ein vollständiger Fix für das Problem ist.

[Complicated]

Panik sollte man nicht haben. Ich will hier jetzt auch nicht Chrome über den Klee loben, aber aktuell scheint es momentan der einzige Browser zu sein, der mit der Strict Site Isolation wirklich einen signifikanten Schutz gegen Spectre beim Surfen liefert.

Mildert natürlich alles nur ab, aber alle anderen Browser wurden davon ein bisschen überrannt, während Chrome das Problem mit einer einfachen Option stark abmildern kann. Das ist schon ein enormer Vorteil, der für die meisten Leute wahrscheinlich auch den meisten Nutzen hat.Und ich sagte der Schutz gegen Spectre V1 entsteht in erster Linie aus verbessertem XSS und den bietet auch ABE bei NoScript. Ich bestreite den enormen Vorteil für Spectre 1 für Chrome gegenüber Lösungen wie NoScript als Addon. Das bezieht sich natürlich nicht auf andere Lücken wo "Strict Site Isolation" tatsächlich Schutz bietet:
Strict Site Isolation ist ja auch nichts anderes als ein erweiterter XSS-Schutz. Den selben Effekt hat man unter FF mit aktiviertem NoScript. Besonders ABE nützt hier sehr viel: https://noscript.net/abe/Das ist im Kontext zu diesem Thema zu sehen.

[Lurtz]

https://www.chromium.org/Home/chromium-security/ssca

Und all das hat den Exploit NOCH IMMER nicht gefixt. Wozu sollten sonst weitere Maßnahmen nötig sein am 23 Januar?

Also man sollte einfach nicht die falsche Information verbreiten "Strict Site Isolation" würde Spectre V1 fixen - dem ist einfach nicht so.
Warum releasen die das eigentlich so spät? Keinen Bock die Changes noch für 63 zu portieren? Finde ich sehr seltsam.

Laut der Seite ist es gefixt wenn man Site Isolation in Chrome 63 aktiviert, aber das kann natürlich Blödsinn sein:
http://xlab.tencent.com/special/spectre/spectre_check.html

[Poook]

Gibt es schon Sammelklagen ? würde sofort unterschreiben ..

In den USA, ja. In Deutschland hat Merkel was dagegen.

[lumines]

Und ich sagte der Schutz gegen Spectre V1 entsteht in erster Linie aus verbessertem XSS und den bietet auch ABE bei NoScript.

Das kannst du auch noch viel öfter sagen, aber es stimmt einfach nicht. Die Abmilderung gegen Spectre kommt bei Chrome mit Strict Site Isolation durch eine striktere Trennung von Webseiten in eigene Prozesse. Bei NoScript / ABE führst du dafür Regeln ein, aber es ändert sich nichts an der Prozessverwaltung. NoScript / ABE bringt mir ohne eine gewisse Sammlung von Regeln erst einmal exakt nichts, wenn ich das Web mit komplett aktivem JavaScript haben will.

Ich bestreite den enormen Vorteil für Spectre 1 für Chrome gegenüber Lösungen wie NoScript als Addon. Das bezieht sich natürlich nicht auf andere Lücken wo "Strict Site Isolation" tatsächlich Schutz bietet:
Das ist im Kontext zu diesem Thema zu sehen.

Ich will fremde JS-Skripte mit einem gewissen Schutz gegen Spectre ausführen, ohne dafür die Skripte auditieren zu müssen. Du kannst dich auch auf den Kopf stellen, aber das musst du einfach mal als Fakt akzeptieren und nicht stillschweigend unter den Teppich kehren, um dann sagen zu können, dass es keinen Unterschied zwischen den beiden Lösungen gibt. Für dich mag JS kein integraler Bestandteil des Webs sein, aber das gilt für 99% der Leute da draußen so nicht.

[Setsul]

Ich habe nicht geschrieben ABE schützt vor Spectre, ich schrieb, dass Site Isolation keinen zusätzlichen Schutz gegen V1 bietet der über das XSS von ABE hinaus geht.
Falsch.
Wenn v1 trotz ABE usw ausgeführt wird dann kann ein Skript auf alle Daten in diesem Prozess zugreifen. Da sollten wir uns doch einig sein?
Wenn der Browser in einem einzigen Prozess läuft dann sind das offensichtlich alle Daten. Mit Site Isolation läuft jeder Tab in einem eigenen Prozess, also kommt das Skript nur noch an die Daten dieses einen Tabs.
Ist das zusätzlicher Schutz? Definitiv.
Ist es das gleiche wie XSS Schutz? Definitiv nicht.
Bringt es etwas wenn das Skript im gleichen Tab (via XSS oder über andere Wege) läuft in dem sich die Daten die man will (z.B. eingegebenes Passwort) sich befinden? Nein.


Auch ist der Angriff in der branch prediction nicht aufzuhalten wenn eine andere Webseite in einem eigenen Prozess ihren Code (in diesem Fall den Angreifercode) ausführt.
Das ist v2. Nicht schon wieder durcheinanderwerfen.

Der Weg um Daten aus dem TLB/Cache auszulesen bleibt erhalten, denn dort wird nach wie vor nicht unterschieden aus welchem Prozess die Sprungvorhersage stammt. Die im Voraus spekulierten Daten liegen dort im Puffer und können von jedem laufenden Prozess auf der CPU ausgelesen werden durch den Exploit.
Auch falsch. Wenn während der Spekulation die Rechte nicht überprüft werden und jeder Prozess auf alles zugreifen kann dann ist das Meltdown (v3), nicht v1.


Mich würde mal interessieren wo ihr bei Google die Aussage lest Strict Site Isolation wäre ein Fix für V1 - die behaupten das interessanterweise nirgendwo. Mitigation!=Fix um das mal gleich vorwegzunehmen.
Hier steht es jedenfalls nicht drin:
https://www.chromium.org/Home/chromium-security/site-isolation

Das ist keine Fix wie man lesen kann. Und es verhindert auch nicht das lesen aus "sonst nicht zugänglichen Daten innerhalb eines Prozesses", es erschwert das lediglich.

https://www.chromium.org/Home/chromium-security/ssca
In addition to UXSS bugs, Site Isolation can also help to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques. Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.

Und all das hat den Exploit NOCH IMMER nicht gefixt. Wozu sollten sonst weitere Maßnahmen nötig sein am 23 Januar?

Also man sollte einfach nicht die falsche Information verbreiten "Strict Site Isolation" würde Spectre V1 fixen - dem ist einfach nicht so.
Niemand hat behauptet es wäre ein vollständiger Fix für v1.
Es geht darum, dass es weit mehr macht als ABE.

Und jetzt nochmal genau lesen.
Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.
Nochmal zum mitschreiben:
V1 funktioniert nur innerhalb eines Prozesses.
Je weniger Daten also in dem Prozess sind in dem ein Skript läuft, desto weniger Daten sind für das Skript zugänglich via v1.

Wenn also jeder Tab in einem eigenen Prozess läuft dann kommt ein Skript nur mit v1 nicht an die Daten der anderen Tabs.
Das bringt aber den Daten im selben Tab und damit selben Prozess gar nichts. Die sind nicht sicher.
Das ist hier das Problem, das noch gefixt werden muss.

Ich hatte dir eigentlich soviel logisches Denkvermögen zugetraut das hier richtig zu interpretieren:
Das Skript läuft in einem eigenen Prozess und dort sind nur die eigenen Daten. V1 kommt nicht in andere Prozesse rein, also sind die sicher.
Also nochmal um sicherzugehen.
Site Isolation:
Andere Tabs sicher.
Tab mit Skript nicht sicher.

[Lehdro]

Einen Schnellschuss wirst du aber auch nicht wollen, oder?
Er fragte nach einem Statement. Kann ja nicht so schwer sagen welche Plattformen direkt noch Support kriegen von Gigabreit....

[lumines]

Er fragte nach einem Statement. Kann ja nicht so schwer sagen welche Plattformen direkt noch Support kriegen von Gigabreit....

Wahrscheinlich macht Gigabyte gerade das, was alle Unternehmen machen, die keine klare Roadmap haben. Eigentlich sind bei ihnen intern schon haufenweise relativ aktuelle Boards EOL, aber sie wiegen gerade ab, welche Boards sie noch beliefern müssen, damit sie nicht in einen PR-Gau laufen. Ist doch immer so. Ohne eine öffentliche Roadmap kann man auch einmal ein paar aktuelle Sachen still auslaufen lassen, was wiederum Geld spart. Nur je nach Schwere und negativem PR-Potential der Lücke für Updates zu sorgen ist wahrscheinlich ein heimlicher Traum vieler Hersteller.

[greg]

Für Sandybridge Systeme soll es doch keine updates geben, hmm

Intel hat doch für Linux bereits ein Microcode Data File bereitgestellt das noch weitaus ältere Prozessoren unterstützt.

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873

Zumindest unter Linux kann man prüfen ob es für den jeweiligen Prozessor angewendet wurde:

https://www.heise.de/forum/heise-online/News-Kommentare/Meltdown-und-Spectre-Intel-patcht-ab-2013-produzierte-Prozessoren-bestaetigt-Performance-Auswirkung/Re-Ruhig-schlafen-mit-Ubuntu-Intel-Microcode-Paket-20180108/posting-31661502/show/

[Gipsel]

Mit Site Isolation läuft jeder Tab in einem eigenen Prozess, also kommt das Skript nur noch an die Daten dieses einen Tabs.
Ist das zusätzlicher Schutz? Definitiv.
Ist es das gleiche wie XSS Schutz? Definitiv nicht.
Bringt es etwas wenn das Skript im gleichen Tab (via XSS oder über andere Wege) läuft in dem sich die Daten die man will (z.B. eingegebenes Passwort) sich befinden? Nein.Nun, die isolieren da sogar noch etwas mehr. Wird ein Adbanner auf der Webpage von einer anderen Seite zugeliefert (wie normalerweise üblich), dann wird wohl sogar das in getrennten Prozessen bearbeitet. Das erschwert also auch diesen Angriffsvektor.

Und auch @Complicated: Zu Spectre v2 habe ich ja schon gesagt, daß sich das aus einem Webbrowser per Script von vornherein nur sehr schwer gezielt triggern läßt (und v2 kommt direkt auch nicht aus dem Prozeß raus; um das zu schaffen, muß man die Ausführung von bestimmtem Code im angegriffenen Prozeß [oder dem Kernel] halbwegs gezielt auslösen können, sonst kann man auch nur im eigenen Prozeß rumwuseln [und dann könnte man auch gleich v1 nehmen, das ist einfacher]). Man hat da nämlich nur sehr indirekt (wenn überhaupt) Zugriff auf die nötigen Werkzeuge, um einen Angriff zu konstruieren (weswegen v1 wohl das dringlichere Problem für einen Browser ist).

[Acid-Beatz]

Guten Abend zusammen,
mal eine Frage an die Administratoren hier, speziell in größeren Firmen: Wie wurde denn bei Euch mit diesem Thema umgegangen, übereiltes Patchen oder erst noch eigene Tests?

Entgegen meiner Vermutung wurde vom Security Board die explizite Anweisung gegeben nichts zu patchen, bis man die genauen Auswirkungen selbiger abschätzen kann.

Greez

[Nitrojedi]

Bei uns wurden die Spectre&Meltdown Patches in den standardmäßigen Patchday von Microsoft integriert (und damit praktisch eine Woche später in den üblichen "Second Tuesday"-Patchzyklus) und werden wie üblich in Wellen verteilt und getestet. Die Vorbereitung bestand lediglich in einem höheren Aufwand unsererseits, um die Voraussetzungen zu prüfen (gesetzter Registry-Schlüssel auf Windows 7 Maschinen, welcher durch McAfee erst mit der gestern erschienenen DAT-Version gesetzt wird.)
Lediglich die möglicherweise notwendigen BIOS-Updates sind mir noch relativ unklar. Wieviel davon als Microcode-Update in einem Windows-Update verteilt werden kann, oder ob dafür tatsächlich ein eigenständiges BIOS-Update erforderlich ist, welches bei uns nur mittels Anhalten des Bitlocker-Schutzes umzusetzen wäre.

EDIT: Auf den ersten Testmaschinen haben wir noch keine negativen Auswirkungen bemerken können. Ich rede hier nicht von "Gaming-Performance -5%", sondern von Business-Applikationen, welche sich (momentan) alle noch unauffällig verhalten.
Der Dienstag veröffentlichte Security Patch für Outlook 2016 (KB4011626) verschluckt den Anhang beim Weiterleiten von Text-only-Mails mit Anhängen, aber dies ist unabhängig von den Spectre-Patches.

[Dicker Igel]

Das liegt wahrscheinlich auch einfach daran, dass es für diesen Zustand keine einfache Analogie mit Brücken, Autos oder Häusern gibt.
Klar gibts 'ne einfache Analogie(pragmatisch): "Der Ersatzschlüssel lag 10 Jahre unbemerkt unterm Abstreicher, aber dann kamen paar ganz pfiffige Leute und haben's der ganzen Welt erzählt."

[BUG]

Guten Abend zusammen,
mal eine Frage an die Administratoren hier, speziell in größeren Firmen: Wie wurde denn bei Euch mit diesem Thema umgegangen, übereiltes Patchen oder erst noch eigene Tests?

Entgegen meiner Vermutung wurde vom Security Board die explizite Anweisung gegeben nichts zu patchen, bis man die genauen Auswirkungen selbiger abschätzen kann.

GreezNach einem kurzen Funktions-Test patchen wir inzwischen alles, die Clients automatsch, ein Großteil der Server auch, nur die Datenbank (MS-SQL) und Host-Server (Hyper-V) werden manuell gepatcht. Allerdings ist heute noch ein Problem (https://social.technet.microsoft.com/Forums/windowsserver/en-US/704b4280-24be-4407-9dbf-ad9609b2e975) mit den RDSH Servern (2012R2) aufgetaucht, die Shadow Funktion (Bildschirm spiegeln für den Mitarbeiter-Support) geht nicht mehr und bricht mit einer Fehlermeldung ab.

Gerade auf den RDSH Servern ist der Patch imho recht wichtig, der Service-Desk und Applikations-Betreuung stand die letzten Tage schon paar mal im Büro. :redface:

**Bios update auf den Host-Server steht noch aus (wird gestetet bzw. warten wir noch auf den Hersteller), ob wir alle Clients/Endgeräte mit einem neuen Bios versorgen können steht noch in den Sternen.

ca. ~1000 User Umgebung mit ca. ~200 Virtuellen & ~30 Physikalischen Servern über mehrere Standorte.

Gruß
BUG

[Complicated]

Falsch.
Wenn v1 trotz ABE usw ausgeführt wird dann kann ein Skript auf alle Daten in diesem Prozess zugreifen. Da sollten wir uns doch einig sein?
Wenn der Browser in einem einzigen Prozess läuft dann sind das offensichtlich alle Daten. Mit Site Isolation läuft jeder Tab in einem eigenen Prozess, also kommt das Skript nur noch an die Daten dieses einen Tabs.
Ist das zusätzlicher Schutz? Definitiv.
Siehst du und hier fällt es mir schwer das ernst zu nehmen was du und auch Gipsel schreiben. Alle beide behauptet ihr, dass "Strict Site Isolation" die Scripte aus verschiedenen Tabs trennen. Dem ist nicht so. Die Trennung erfolgt Quellbasierend. Sprich Scripts im selben Tab mit einer anderen Herkunft (Cross-site!!) werden isoliert im Prozess. Z.B. Werbeeinblendungen. Und genau DESHALB ist es ein erweiterter XSS-Schutz und sonst gar nichts. Läuft das Script auf der selben Quelle ausgeliefert wie die Webseite die du besuchst, dann wird auch das Script in keinem isolierten Prozess ausgeführt.

Wird ein Script in die besuchte Webseite eingeschleust und von dort aus ausgeführt bekommt es auch keinen eigenen Prozess. Daraus folgernd ist es ein XSS-Schutz und mehr nicht. Ich weiß auch in meinem Firefox mit NoScript genau welche Webseiten bei mir Scripte ausführen dürfen und welche nicht. Und ebenso wie bei NoScript gibt es Whitelisting bei "Strict Site Isolation" wenn Quellen und deren Medien Probleme machen mit diesem Schutz.
This mode allows you to provide a list of specific origins that will be given dedicated processes, rather than isolating all sites. The main advantage to this mode is that it typically uses less memory than isolating all sites. If using this approach, we recommend including any site that you log into on the list. (Note that subdomains are included, so listing https://google.com will also protect https://mail.google.com.) This mode can be enabled in either of the following ways:
Und zudem:

In addition to the recommended cases above, Chrome will also do its best to protect responses labeled with any of the MIME types above and without a "nosniff" header, but this has limitations. Many JavaScript files on the web are unfortunately labeled using some of these MIME types, and if Chrome blocked access to them, existing websites would break. Thus, when the "nosniff" header is not present, Chrome first looks at the start of the file to try to confirm whether it is HTML, XML, or JSON, before deciding to protect it. If it cannot confirm this, it allows the response to be received by the cross-site page's process. This is a best-effort approach which adds some limited protection while preserving compatibility with existing sites. We recommend that web developers include the "nosniff" header to avoid relying on this approach.So richtig funktionieren wird es nur wenn die Webseiten Betreiber mit machen - davon ist bei Hackern ja ganz sicher auszugehen /Ironie off.

[user77]

In wiefern betrifft mich das jetzt als it verantwortlicher der Firma?

Haben mehrere HP Server und HP PCs / Workstations mit Intel Prozessoren.

Bios Updates? Windows Updates? Esx Updates?

[Nitrojedi]

In wiefern betrifft mich das jetzt als it verantwortlicher der Firma?

Haben mehrere HP Server und HP PCs / Workstations mit Intel Prozessoren.

Bios Updates? Windows Updates? Esx Updates?

https://www.reddit.com/r/sysadmin/comments/7p8yyv/vmware_released_the_patches_for_spectre_at_the/

Windows Updates evaluieren, Virenschutz prüfen (https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0), eventuell notwendige Registry-Schlüssel setzen (Hyper-V und RDS Hosts benötigen imo spezielle Keys), und danach die BIOS Update-Verfügbarkeit bei HP prüfen.

[BUG]

Bios Updates? Windows Updates? Esx Updates?

HPE: http://h22208.www2.hpe.com/eginfolib/securityalerts/SCAM/Side_Channel_Analysis_Method.html (für die Gen8 Server soll morgen was kommen)

VM-Ware: https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html

Microsoft: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

Und wie Nitrojedi schon schrieb, Virenschutz beachten/prüfen ob er mit dem neuen Windows NT-Kernel Update zurecht kommt.

Gruß
BUG

[user77]

https://www.reddit.com/r/sysadmin/comments/7p8yyv/vmware_released_the_patches_for_spectre_at_the/

Windows Updates evaluieren, Virenschutz prüfen (https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0), eventuell notwendige Registry-Schlüssel setzen (Hyper-V und RDS Hosts benötigen imo spezielle Keys), und danach die BIOS Update-Verfügbarkeit bei HP prüfen.

Vielen Dank Intel / AMD. Wir betreuen auch noch ca. 80 Server und 400 Clients unserer Kunden und Wir haben ja sonst nichts zu tun...

[Dorn]

Nach dem die Windows Update Suche auf meinem Laptop und Pc jeweils Intel immer noch nix gefunden hat, habe ich es bei Microsoft runter geladen. Sonst noch jemand Probleme?
Wenigstens sind jetzt meine System gegen Meltdown geschützt.

[Nitrojedi]

Vielen Dank Intel / AMD. Wir betreuen auch noch ca. 80 Server und 400 Clients unserer Kunden und Wir haben ja sonst nichts zu tun...


Tja, jedes Unternehmen >10 Mitarbeiter hat momentan diese Probleme am Hals.
Was mich dabei nur immer wieder erstaunt ist, dass das Problem vor einem halben Jahr an Intel gemeldet wurde, und es so wirkt, als sei erst mit Bekanntwerden des Problems in der Presse an einer Lösung gearbeitet worden ...

Die Unternehmen sind dann die Leidtragenden, die die QA übernehmen, die Minderperformance hinnehmen und auf undurchsichtige, undokumentierte und viel zu späte Gegenmaßnahmen reagieren müssen.


Nach dem die Windows Update Suche auf meinem Laptop und Pc jeweils Intel immer noch nix gefunden hat, habe ich es bei Microsoft runter geladen. Sonst noch jemand Probleme?
Wenigstens sind jetzt meine System gegen Meltdown geschützt.
Setzt du ein Antivirenprogamm ein? Wenn ja welches?

[Birdman]

Läuft das Script auf der selben Quelle ausgeliefert wie die Webseite die du besuchst, dann wird auch das Script in keinem isolierten Prozess ausgeführt.
Und wieso verstehst Du immer noch nicht, dass uns das allen sonnenklar ist und dass eben genau das kein wirkliches Problem ist, wenn man "Strict Site Isolation" verwendet?

Wenn Schadcode nicht von einer fremden Site kommt, sondern in die Site injected wurde welche Du grad besuchst, dann bist Du mit ABE und allen andern sinnvollen Scriptblockern ebenfalls gefickt - denn das Script kommt von same-origin und wird deswegen ausgeführt.
Und da Du ja keine "Strict Site Isolation" verwendest (ist gemäss deiner Aussage ja nichts wert) hat dieses Script dann via Spectre Zugriff auf die Daten aller übrigen offenen Tabs.

Mit "Strict Site Isolation" kann das nicht passieren - und ja, es ist kein direkter XSS Schutz, denn es verhindert nicht das ausführen von allenfalls bösartigen externen Scripts.....aber es ist ein indirekter Schutz, da es diese Scripts nicht im Speicherbereich von deinen Tabs rumwuseln lässt.

Damit sage ich nicht dass "Strict Site Isolation" dass Allheilmittel ist.
Einfach so irgendwelche Scripts ausführen will keiner, denn es gibt da draussen ja noch mehr als nur Spectre, was man für Missbräuche nutzen könnte.

Aber die ABE Funktionsweise im Falle von Specte mit dem "Strict Site Isolation" Feature von Chrome gleichzustellen, ist einfach nur grober Nonsens...

[Dorn]

Setzt du ein Antivirenprogamm ein? Wenn ja welches? PC keins, Notebook Windows Defender

[Nitrojedi]

PC keins, Notebook Windows Defender

Ich habe an meinem Windows 10 Client den Defender gekillt und musste den Registry-Schlüssel manuell setzen, um über Windows Update das Sicherheitsupdate zu erhalten. Hast du auch an dem PC mit Defender keine automatischen Updates erhalten? Defender setzt den Schlüssel seit einer Woche automatisch, so wie mittlerweile die meisten anderen Antivirenprogramme.


Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat
Value: cadca5fe-87d3-4b96-b7fb-a231484277cc
Type: REG_DWORD
Data: 0x00000000

[gravitationsfeld]

Tja, jedes Unternehmen >10 Mitarbeiter hat momentan diese Probleme am Hals.
Was mich dabei nur immer wieder erstaunt ist, dass das Problem vor einem halben Jahr an Intel gemeldet wurde, und es so wirkt, als sei erst mit Bekanntwerden des Problems in der Presse an einer Lösung gearbeitet worden ...
Die Kernel-Patches waren seit Monaten in Arbeit. Sowas aendert man nicht mal kurzfristig.

Die Antiviren-Situation war unausweichlich, weil man nicht der ganzen Antivirus-Industrie vertrauen kann den Bug nicht zu leaken.

Und ganz ehrlich, dass viele Antivirus-Programme rootkits (!) installieren um an Windows-Sicherheitsvorkehrungen vorbei zu kommen spricht Baende. Da spielt Microsoft nur mit, weil sonst wieder alle "Kartell!" schreien wuerden.

[Dorn]

Ich habe an meinem Windows 10 Client den Defender gekillt und musste den Registry-Schlüssel manuell setzen, um über Windows Update das Sicherheitsupdate zu erhalten. Hast du auch an dem PC mit Defender keine automatischen Updates erhalten? Defender setzt den Schlüssel seit einer Woche automatisch, so wie mittlerweile die meisten anderen Antivirenprogramme.


Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat
Value: cadca5fe-87d3-4b96-b7fb-a231484277cc
Type: REG_DWORD
Data: 0x00000000
Beim PC ist der Defender deaktiviert. Jup habe bei beiden mehr mals die Suche manuell angestoßen plus Problembehandlung Windows Update.
Habs mir halt für beide Rechner dann über den Microsoft Update Katalog geholt.
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892

Falls im Februar wieder auf beiden Systemen nichts passieren sollte, muss ich mal mehr unter die Haube schauen.

[Setsul]

@Complicated:
Scheiterst du wirklich an dieser hochkomplexen Formulierung?


Also nochmal um sicherzugehen.
Site Isolation:
Andere Tabs sicher.
Tab mit Skript nicht sicher.

Ja, innerhalb des Tabs kann es auch nicht mehr machen als auch ABE erkennen würde*.
Es geht darum dass mit v1 ein Skript von einer Website auf die Daten einer völlig anderen Website in einem völlig anderen Tab zugreifen könnte. Das Skript kommt von einer Website und greift nicht spekulativ auch nur auf die eigenen Daten zu. XSS Schutz bringt dir da rein gar nichts. Strict Site Isolation schon.


*Sofern ABE das Skript komplett blockiert. Wenn es ausgeführt wird dann funktioniert v1 ohne jegliche Einschränkung. Site Isolation ist natürlich nur dann besser wenn das Skript obwohl im selben Tab trotzdem wegen anderer Herkunft in einem anderen Prozess landet.

[Complicated]

@Birdman
Zunächst einmal kannst du sachlich bleiben. Wir reden hier ausschließlich über Browser Security Feature im Kontext von Meltdown/Spectre.
Wenn Schadcode nicht von einer fremden Site kommt, sondern in die Site injected wurde welche Du grad besuchst, dann bist Du mit ABE und allen andern sinnvollen Scriptblockern ebenfalls gefickt - denn das Script kommt von same-origin und wird deswegen ausgeführt.Das schreibe ich die ganze Zeit schon. Zu keiner Zeit habe ich ABE mehr Schutzfunktion zugesprochen. Aber das tue ich im Kontext zu Spectre auch Strict Site Isolation nicht. Ich schrieb gleichwertig.

Und da Du ja keine "Strict Site Isolation" verwendest (ist gemäss deiner Aussage ja nichts wert) hat dieses Script dann via Spectre Zugriff auf die Daten aller übrigen offenen Tabs.

Mit "Strict Site Isolation" kann das nicht passieren - und ja, es ist kein direkter XSS Schutz, denn es verhindert nicht das ausführen von allenfalls bösartigen externen Scripts.....aber es ist ein indirekter Schutz, da es diese Scripts nicht im Speicherbereich von deinen Tabs rumwuseln lässt.
Ich habe nirgendwo etwas von "nichts Wert" geschrieben. XSS-Protection ist immer gut und sollte so gut wie möglich genutzt werden. Nur sollte man keine magischen Schutz herbei orakeln wo keiner vorhanden ist.

Ob die Scripte im Speicherbereich der Tabs rumwuseln ist für Spectre überhaupt nicht von belang, da Spectre die Daten aus spekulativ ausgeführten Codezeilen ausliest die im TLB/Cache nicht geschützt sind durch irgendeinen Mechanismus den Chrome zur Verfügung stellt.

Nur um mal jedem hier in Erinnerung zu rufen, dass die Variante 1 von Spectre immer im selben Prozess arbeitet:
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html


A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.


Misleading the branch prediction and bouncing the cache lines works the same way as for the first eBPF program, except that now, the cache line holding the length of victim_map must also be bounced to another core.

[BBig]

Unser Thinkpad E570 hat gerade ein Bios-Update für CVE-2017-5754 reinbekommen. Denke das L560 wird auch noch was bekommen.

Bei MSI weiterhin Totenstille... :ugly:

Das Forum von MSI ist wirklich - mir fällt kein richtiges Wort dafür ein - vll verloren oder sinnfrei? :freak:
Es ist zwar auf der msi.com-Domain, und wenn man sich ein "Support-Konto" anlegt, dann wird mal quasi auf dieses Forum gestoßen, aber Support sollte man da nicht erwarten! :eek:

Sie werden auch nicht müde zu betonen:

This forum is a support community for users of MSI products, managed and maintained by users on behalf of MSI.

https://forum-en.msi.com/index.php?topic=64858.0

Auch der schon erwähnte Thread zu Meltdown and Spectre patch Mitigations (https://forum-en.msi.com/index.php?topic=297707.0) spottet jeder Beschreibung, :redface:

==//==

Sei es drum, MSI hat endlich mal was zu Meltdown & Spectre verlauten lassen: https://www.msi.com/news/detail/rKUC2bI3D7-qQwKu2sMknN64chmZ522Lud9g_cONY0PNhahW-TFJ96dI7K7NA9rKUsihP5smlrCseaHQstFxJw~~

Es kommen nur BIOS-Updates für X299-series, 200-series, 100-series and X99-series und neuer.

[gravitationsfeld]

Asus hat immer noch kein Update fuer's Z170-P rausgegeben. Auch nicht viel besser.

[shane~]

Hab gestern das aktuelle Bios, welches das Microcode Update enthält, für mein HP ProBook 450 G2 (i5 5200U [Broadwell-U] / 8 GB RAM) eingespielt, die Auswirkungen auf die SSD I/O Performance sind enorm :eek:

Samsung SSD 840 256 GB (gemessen mit integriertem Samsung Magican 5.1.0 Performance Benchmark)

BIOS 01.44 (23.07.2017)

Read: 556 mb/s - Write: 256 mb/s - IOPS read: 82,034 - IOPS write: 59,268

BIOS 01.45 (09.01.2018)

Read: 552 mb/s - Write: 253 mb/s - IOPS read: 34,869 - IOPS write: 31,870

Heftig. Man merkt vor allem beim Boot Vorgang einen deutlichen Einbruch, subjektiv ungefähr doppelt so lange :mad:

Ich bin wieder zurück auf das alte Bios.

https://i.imgur.com/lbAdeLH.png https://i.imgur.com/oi4wlqH.png

[Rancor]

Ist das beim Kaffee See auch so ?

[deekey777]

An Update on AMD Processor Security (http://www.amd.com/en/corporate/speculative-execution)

At AMD, security is our top priority and we are continually working to ensure the safety of our users as new risks arise. As a part of that vigilance, I wanted to update the community on our actions to address the situation.

Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.

We believe this threat can be contained with an operating system (OS) patch and we have been working with OS providers to address this issue.
Microsoft is distributing patches for the majority of AMD systems now. We are working closely with them to correct an issue that paused the distribution of patches for some older AMD processors (AMD Opteron, Athlon and AMD Turion X2 Ultra families) earlier this week. We expect this issue to be corrected shortly and Microsoft should resume updates for these older processors by next week. For the latest details, please see Microsoft’s website.

Linux vendors are also rolling out patches across AMD products now.

GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.

While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.


GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.

We believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture and no mitigation is required
.

There have also been questions about GPU architectures. AMD Radeon GPU architectures do not use speculative execution and thus are not susceptible to these threats.

------------------------------------
Microsoft ist sehr transparent, wenn es um Intel geht. X-D

[Denniss]

https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

Intel musste wohl einige Microcodes zurückziehen, so auch diverse Mainboardhersteller damit bestückte Biosversionen.
Es gab hier im Thread schon diverse Meldung bezüglich Instabilitäten einiger älterer Intel CPUs.

[BBig]

Kommentar zu Meltdown & Spectre: Chaos statt Kundendienst
@ heise.de (https://www.heise.de/newsticker/meldung/Kommentar-zu-Meltdown-Spectre-Chaos-statt-Kundendienst-3938140.html)

...
Wie kann es sein, dass sechs Monate nach Bekanntwerden gravierender Sicherheitsmängel keine konkreten Listen mit Produkten und den jeweils geplanten Updates vorliegen?
...

Das ist der Moneyquote für mich!
Nach 6 Monaten liegen keine Software-Updates, keine Kernel-Updates und keine BIOS-Updates bereit, ja, selbst Listen wer wie betroffen ist, gibt es einfach nicht. Was haben alle 6 Monate gemacht?

[Bucklew]

AMD gibt jetzt doch zu von Spectre betroffen zu sein, MicroCode Updates wird es aber nur optional und nur für RyZen/Epic geben.

Daneben werden für die Grafikchips nur die Chips selbst erwähnt, der Treiber wird ausgespart. Dabei kann durchaus davon ausgegangen werden, dass selbiger ähnliche Probleme wie NVIDIA hat, die ja bereits einen gepatchten Treiber ausliefern.

http://www.amd.com/en/corporate/speculative-execution

[][immy]

AMD gibt jetzt doch zu von Spectre betroffen zu sein, MicroCode Updates wird es aber nur optional und nur für RyZen/Epic geben.

Daneben werden für die Grafikchips nur die Chips selbst erwähnt, der Treiber wird ausgespart. Dabei kann durchaus davon ausgegangen werden, dass selbiger ähnliche Probleme wie NVIDIA hat, die ja bereits einen gepatchten Treiber ausliefern.

http://www.amd.com/en/corporate/speculative-execution
Das haben sie doch schon die ganze Zeit zugegeben. Soweit ich verstanden habe, können im Gegensatz zu den Intel-Problemen nur lesende Zugriffe vorgenommen werden. Bei Intel kann hingegen noch geschrieben werden über das dritte Problem.

[Ganon]

Nein, Schreiben geht nirgendwo.

[Schnoesel]

Das haben sie doch schon die ganze Zeit zugegeben.

So siehts aus und optional, bedeutet nicht, dass sie die Codes nicht zur Verfügung stellen, sondern es Ihrer Ansicht nach nicht nötig wäre, da eben near zero risk Wahrscheinlichkeit. Der Patch macht aus near zero risk dann wohl zero risk.

Dass Ihre Grafikchips nicht betroffen sind ist ebenso korrekt und die Frage ist ob der AMD Treiber ein Update benötigt, denn der AMD Treiber hat nun mal im Gegensatz zu Geforce Experience keine Account Bindung mit Passwörtern. der Treiber dürfte schlicht und ergreifend keinerlei "interessante" Daten beinhalten. Hier fällt Nvidias Sammelwut von Daten ihnen wieder auf den Kopf.

[Bucklew]

[immy;11602652']Das haben sie doch schon die ganze Zeit zugegeben.
Nein?

https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html

The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

[Schnoesel]

AMDs Aussage ist völlig richtig.

[ndrs]

nur für RyZen/Epic
Bitte nicht aus dem Zusammenhang reißen. Ryzen und Epic ab dieser Woche. Ältere etwas später.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks.

[Ganon]

Scrollt doch einfach in dem Report von AMD nach unten. Da steht doch, was sie gesagt haben xD

[Birdman]

deekey777 hat doch weiter oben das umfangreiche Statement von AMD verlinkt.
Da steht exakt das drin was man an Informationen benötigt:

a) Für die Mitigation der Spectre_v1 Lücke (für welche AMD vollumfänglich verwundbar ist) gibts es OS-Patches welche das Problem so gut wie zur Zeit technisch möglich eindämmt.

b) Für die Mitigation der Spectre_v2 Lücke (für welche AMD ein "near-zero" Risk ausgibt) gibt es Microcode/Firmware updates, welche dann im Zusammenspiel mit OS-Patches das Risiko noch weiter minimieren.


Bei Punkt B) ist es ja so, dass die OS Patches/Anpassungen auf entsprechende CPU Features angewiesen sind, welche mit diesen Microcode Updates in die Prozessoren einfliessen.
D.h. die Microcodes fixen nicht das Problem, sondern geben der Software die Möglichkeit, dies dann zu tun.

Als AMD Privatuser kann man imho zu Zeit aber auf die Microcodes pfeifen und auch die entsprechenden OS-Fixes hierfür deaktivieren. Das Risiko ist auch ohne diese Massnahmen schon sehr gering. (es sei denn die NSA hat einem explizit im Visier - dann sieht es vielleich anders aus)

[Rancor]

Tchjooo was mache ich nun mit meinem 3570k meiner Freundinn ^^ :D

[Freestaler]

Ich bin @ at CB noch auf die Intel Benchmark vom 11.1 gestossen..

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Blog-Benchmark-Table.pdf

Intel sieht hier Win10 stärker betroffen als Win7. Wobei MS das anders sieht. Interessant. Ich glaub das ist bei beiden mehr Marketing als Facten am start.

Und wie Test Intel "DX11 Gaming performance" im CPU Limit wenn die nur IntelGPU verwenden? Dann ist man doch sowieso direkt im GPU Limit.

[Complicated]

https://support.lenovo.com/de/de/solutions/len-18282
The following guidance is specific to Lenovo Personal Computing (PCSD) offerings.

Withdrawn CPU Microcode Updates: Intel provides to Lenovo the CPU microcode updates required to address Variant 2, which Lenovo then incorporates into BIOS/UEFI firmware. Intel recently notified Lenovo of quality issues in two of these microcode updates, and concerns about one more. These are marked in the product tables with “Earlier update X withdrawn by Intel” and a footnote reference to one of the following:

*1 – (Kaby Lake U/Y, U23e, H/S/X) Symptom: Intermittent system hang during system sleep (S3) cycling. If you have already applied the firmware update and experience hangs during sleep/wake, please flash back to the previous BIOS/UEFI level, or disable sleep (S3) mode on your system; and then apply the improved update when it becomes available. If you have not already applied the update, please wait until the improved firmware level is available.

*2 – (Broadwell E) Symptom: Intermittent blue screen during system restart. If you have already applied the update, Intel suggests continuing to use the firmware level until an improved one is available. If you have not applied the update, please wait until the improved firmware level is available.

*3 – (Broadwell E, H, U/Y; Haswell standard, Core Extreme, ULT) Symptom: Intel has received reports of unexpected page faults, which they are currently investigating. Out of an abundance of caution, Intel requested Lenovo to stop distributing this firmware.

[Schnoesel]

Intel sieht hier Win10 stärker betroffen als Win7. Wobei MS das anders sieht. Interessant. Ich glaub das ist bei beiden mehr Marketing als Facten am start.

Darunter fallen natürlich auch die Intel Benches:

"Interessant ist der Benchmark Sysmark 2014 SE Responsiveness, da er den eingesetzten Datenträger mittestet. Bisherige Ergebnisse zeugten von erheblichen Einbrüchen bei SSDs, vor allem wenn sie über PCI-Express 3.0 x4 samt NVMe-Protokoll angebunden werden. Die Sicherheits-Updates verlangsamen das Ergebnis mit dem Core i7-6700K unter Windows 10 um 21 Prozent, unter Windows 7 kurioserweise gar nicht. Beim Core i7-8700K unter Win 10 sinkt das Ergebnis um 12 Prozent. Angemerkt sei, dass Intel mit einer hauseigenen 600p getestet hat, die zu den langsamsten NVMe-SSDs gehört und teilweise nur minimal schneller als SATA-6Gbit/s-Modelle arbeitet (dafür auch entsprechend günstig ist). Bei spezifischen SSD-Tests mit schnelleren Modulen wurden schon Leistungshalbierungen verzeichnet. Ein PCGH-Leser hat uns seine Ergebnisse mit einer 1 TByte großen Samsung SSD 960 Evo zugesandt, die das bisherige Bild bestätigen"

http://www.pcgameshardware.de/Sicherheit-Thema-229955/News/Meltdown-Spectre-Intel-Benchmarks-1247650/

[][immy]

Ich bin @ at CB noch auf die Intel Benchmark vom 11.1 gestossen..

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Blog-Benchmark-Table.pdf

Intel sieht hier Win10 stärker betroffen als Win7. Wobei MS das anders sieht. Interessant. Ich glaub das ist bei beiden mehr Marketing als Facten am start.

Und wie Test Intel "DX11 Gaming performance" im CPU Limit wenn die nur IntelGPU verwenden? Dann ist man doch sowieso direkt im GPU Limit.
interessanter fände ich immer noch benches von Ivy- & Sandy-bridge, da die immer noch stark verbreitet sind. Wie sieht es da mit der Performance aus. Je älter desto schlimmer soll es ja sein.

Zudem, welche CPU kann man derzeit eigentlich für einen PC kaufen die nicht in irgendeiner art und weise betroffen ist (von Intel).
Das schlimme ist ja eigentlich das ich mir vor kurzem überlegt hatte auf Ryzen umzusteigen, aber mit dem Budget das ich mir vorgestellt hatte, reichte es grad mal für ein Sidegrade. Dat lohnt also nicht.

[Bucklew]

Bitte nicht aus dem Zusammenhang reißen. Ryzen und Epic ab dieser Woche. Ältere etwas später.
Hast Recht, hab den Nachsatz überlesen.

[deekey777]

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

Aber was soll man von mfi sonst erwarten?

[dildo4u]

Ashampoo Spectre Meltdown CPU Checker

https://www.ashampoo.com/de/eur/pin/1304/sicherheitssoftware/Ashampoo-Spectre-Meltdown-CPU-Checker

Ryzen 1600 Win 10 mit Software Update aber ohne Bios Fix.


http://abload.de/img/ryzencxr86.png

[Annator]

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

Aber was soll man von mfi sonst erwarten?

Das ist ganz klar Fakenews mit der Überschrift.

AMD rudert zurück: Prozessoren doch von Spectre 2 betroffen, Microcode-Updates für Ryzen und Epyc in Kürze

So wäre es keine Fakenews.

[StefanV]

Tchjooo was mache ich nun mit meinem 3570k meiner Freundinn ^^ :D
Na, das, was man schon seit Dekaden von dir verlangt:
Wegwerfen und neu kaufen, was denn sonst??

[Rancor]

Na, das, was man schon seit Dekaden von dir verlangt:
Wegwerfen und neu kaufen, was denn sonst??

Min 350€ wegen einer Kack Sicherheitslücke nur weil Intel es nicht nötig hält ihre älteren CPUs zu fixen.

Für Overwatch und Co. reicht die CPU 100x aus. Naja so kann ich es wenigstens vertreten mir nen Pinnacle Ridge zu kaufen. Den R5 1600 vererbe ich dann eben :D

[][immy]

Min 350€ wegen einer Kack Sicherheitslücke nur weil Intel es nicht nötig hält ihre älteren CPUs zu fixen.

Für Overwatch und Co. reicht die CPU 100x aus.
Hab die gleiche CPU. Bei 350€ bleibt es nicht wenn du mindestens etwas gleichwertiges möchtest. Du musst ja, CPU, Mainboard und Ram austauschen. Bzw, wenn du darauf vertrauen willst das die Probleme mit Haswell noch gefixed werden, könntest du den Ram noch wiederverwenden.

[Rancor]

Doch bleibt es. Ich würde nur 8 GB Ram nehmen. Hat sie jetzt auch und das reicht dafür.

[deekey777]

Ashampoo Spectre Meltdown CPU Checker

https://www.ashampoo.com/de/eur/pin/1304/sicherheitssoftware/Ashampoo-Spectre-Meltdown-CPU-Checker

Ryzen 1600 Win 10 mit Software Update aber ohne Bios Fix.


http://abload.de/img/ryzencxr86.png
Da könnte man endlich die Unsicherheit ausnutzen und Spamware, Viren, Spyware, Adware über vermeintliche Checker vertreiben. :uup:

Dass ein Ryzen einem Intel gleichgesetzt wird (Spectre), finde ich nicht schön.

https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/

[Gipsel]

https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/Jetzt wissen wir auch, warum AMD für Spectre v2 von einem nur kleinem Risiko der Ausnutzung ausgeht. Wie hier im Thread schon vermutet, speichern die im Branch Target Buffer nicht nur ein paar Bits der Adresse (wie intel) sondern deutlich mehr, nämlich offenbar die komplette Adresse. Um den BTB zu "vergiften" muß man also Code an exakt der gleichen Adresse ausführen wie der angegriffene Code (was wegen virtuellem Speicher im Prinzip geht, solange dort im BTB keine physischen Adressen abgelegt sind [AMD hat seit Ryzen den ITLB im Branch prediction-Pfad, also hmm]). Das macht es tatsächlich schwieriger.

[deekey777]

AMD ist genervt: https://www.hardocp.com/news/2018/01/11/amd_doubles_down_on_previous_spectre_meltdown_statments

We have seen some initial stories with a couple of inaccuracies so want to make sure we are being perfectly clear.

* There is no change to AMD’s position on our susceptibility to GPZ Variant 1 or GPZ Variant 2 (collectively called Spectre in many news reports).
* The update in relation to Variant 2 is that even though Variant 2 has not been demonstrated to work on AMD products due to differences in our micro architecture, out of an abundance of caution we are making optional micro code updates available to further contain the threat.

Again, to make it perfectly clear we have not changed our statement erlated to our susceptibility to Variant 2. Let me know if you have questions or need additional details.

Keine Ahnung, was die Quelle ist.
https://www.reuters.com/article/brief-amd-says-no-change-to-cos-position/brief-amd-says-no-change-to-cos-position-on-susceptibility-to-gpz-variant-1-or-gpz-variant-2-idUSFWN1P60X7

AMD SAYS THERE IS NO CHANGE TO AMD’S POSITION ON OUR SUSCEPTIBILITY TO GPZ VARIANT 1 OR GPZ VARIANT 2 (COLLECTIVELY CALLED SPECTRE IN NEWS REPORTS)

[Linmoum]

Wenn man dann sowas wie von heise lesen darf, wäre ich auch genervt.

[Birdman]

Aber was soll man von mfi sonst erwarten?
make it difficult ist aber halt schon nicht das gleiche Wording wie near zero risk, daher kann man durchaus davon ausgehen, dass AMDs initiale Analyse etwas zu optimistisch war.

Edit: dann soll AMD halt bei Updates den gleichen, oder zumindest gleich starken Wortlaut verwenden, wenn sie Missverständnisse verhindern wollen

[deekey777]

make it difficult ist aber halt schon nicht das gleiche Wording wie near zero risk, daher kann man durchaus davon ausgehen, dass AMDs initiale Analyse etwas zu optimistisch war.
Die Meldung von Reuters ist von gestern, ich habe mein Zweifel, dass Herr Fischer - selbst wenn der Artikel heute Nacht veröffentlicht wurde, - dieses Stament übersehen hat. Gleiches gilt für den HardOCP-Beitrag.


-----------------------------
Der Ashampoo-Test sagt, dass mein x5-Z8350 weder gegen Spectre noch Meltdown abgesichert ist.

[maguumo]

Abgesehen davon fand die "initiale Analyse" wohl vor 6 Monaten statt als den Herstellern die Infos gesteckt wurden. Da wird sich in den letzten Tagen bei keinem etwas bezüglich der Risikoeinschätzung geändert haben.

[Gipsel]

make it difficult ist aber halt schon nicht das gleiche Wording wie near zero risk, daher kann man durchaus davon ausgehen, dass AMDs initiale Analyse etwas zu optimistisch war.Nun, wenn das bei arstechnica stimmt, daß AMD bei Ryzen die vollständige Adresse des Branches im BTB speichert (der indirect branch predictor nutzt auch diese Einträge), dann muß man für einen erfolgreichen Angriff per Spectre v2 den zum Training benutzten Branch im Code des Angreifers auf die exakt gleiche Adresse legen wie den Branch im angegriffenen Code, man benötigt also die Möglichkeit, seinen Code von einer bestimmten Adresse auszuführen (da muß man ihn also hinlegen), damit man überhaupt eine Möglichkeit bekommt (bei intel nutzt der indirect predictor offenbar die Adresse überhaupt nicht und im BTB wird nur ein 10 oder 12bit Schnipsel der Adresse genutzt, da geht das Aliasing also recht leicht). Und AMD soll laut dem Artikel auch gar kein IBRS für Zen anbieten, weil das unnötig sei (nur IBPB und STIBP).

Edit:
Vor einer Woche schrieb ich bereits das dazu:
Für einen wirklichen Fix [für Spectre v2] benötigt man eine überarbeitete Sprungvorhersage, z.B. durch mehr Bits beim Speichern der Adresse (+ Context ID und dann noch einen Hash davon?) eines Sprungs im Branch Target Buffer (so daß man nicht oder nur sehr viel schwieriger die Zielvorhersage durch andere Sprünge an anderen Adressen und anderen Kontexten spoofen kann [intel benutzt momentan wohl nur ganz simpel 12 Bits der Adresse, wodurch man da ganz gut ein Aliasing und damit falsche Hits konstruieren kann]).
[..]
Das blöde an Spectre v2 ist auch, daß selbst die Gegenmaßnahmen wie für Spectre v1 alleine nicht wirklich helfen würden, wenn sich die Zielvorhersage der Sprungvorhersage noch beeinflussen läßt. Damit kann man dann nämlich beliebige Codeschnipsel im Speicher (Gadgets) anspringen, die sich zu sinnvollem Code zur Exfiltration zusammenbauen lassen. Hier hilft wirklich nur den Branch Target Buffer bei jedem Syscall per Software zu flushen (dafür gibt es die Micocodeupdates, um das überhaupt zu ermöglichen) oder die Hardware für die Indizierung des BTBs wie oben erwähnt insgesamt aufzubohren, um dort keine falschen Hits zu bekommen.

Vermutlich meint AMD übrigens genau das mit der "near zero vulnerability" für Spectre v2. Die Indizierung in den BTB wird bei ihnen schlicht mehr Bits benutzen (und/oder die Adresse hashen), wodurch die Atacke schwieriger wird. Details sind leider nicht bekannt, auch was die Unterschiede zwischen den verschiedenen CPU-Generationen angeht.

[Pirx]

...bei intel nutzt der indirect predictor offenbar die Adresse überhaupt nicht und im BTB wird nur ein 10 oder 12bit Schnipsel der Adresse genutzt, ...
So holt sich wohl Intel einen Teil des Performancevorteils und das wird auch weiterhin so klappen, da extra für Intel der Aufwand betrieben wird, die Sicherheitsprobleme per Software auszubügeln, toll.

[Schnoesel]

Sandy Bridge trifft es hart:

https://www.computerbase.de/2018-01/meltdown-spectre-amd-intel-benchmarks/

Ich hoffe es kommen noch weitere Messreihen.

[maguumo]

So holt sich wohl Intel einen Teil des Performancevorteils und das wird auch weiterhin so klappen, da extra für Intel der Aufwand betrieben wird, die Sicherheitsprobleme per Software auszubügeln, toll.

Ich weiß nicht wie viel Leistung man damit rausholt (vielleicht sogar garnichts und man spart sich nur etwas Aufwand?) aber die Lücke per Software dicht zu machen kostet sicherlich ein Vielfaches des möglicherweise vorhandenen Vorteils. Von daher werden sie das für zukünftige Designs sicherlich umbauen.

[Complicated]

Interessantes zu den Microcode Updates und den jeweiligen unterschiedlichen Einstellungen der Hersteller und einzelner Modell-Familien für PTI, IBRS und IBPB findet man bei Redhat:
https://access.redhat.com/articles/3311301
PTI ist ja soweit klar für Meltdown nur auf Intel Systemen. Die beiden anderen, die branch prediction betreffenden, Einstellungen haben auch verschiedene mögliche Werte wenn sie aktiviert sind:
Architectural Defaults

By default, each of the 3 tunables that apply to an architecture will be enabled automatically at boot time, based upon the architecture detected.

Intel Defaults:

pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)

AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.

pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates

Wie aus den detaillierten Beschreibungen zu lesen ist, kann die Variante 2 bei älteren Intel CPUs, welche kein Microcode Update erhalten nicht gefixed werden. IBRS und IBPB bleiben deaktiviert und PTI wird aktiviert, wodurch vermutlich auch der große Performance-Einbruch entsteht.

Indirect Branch Restricted Speculation (ibrs)

“noibrs”/ibrs_enabled controls the IBRS feature in the SPEC_CTRL model-specific register (MSR) when SPEC_CTRL is present in cpuid (post microcode update). When ibrs_enabled is set to 1 the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.

Customer and vendors can disable the ibrs implementation in microcode by passing "noibrs" to the kernel command line at boot, or dynamically with the debugfs control below:

# echo 0 > /sys/kernel/debug/x86/ibrs_enabled

Indirect Branch Prediction Barriers (ibpb)

“noibpb”/ibpb_enabled controls the IBPB feature in the PRED_CMD model-specific register (MSR) if either IBPB_SUPPORT or SPEC_CTRL is present in cpuid (post microcode update). When ibpb_enabled is set to 1, an IBPB barrier that flushes the contents of the indirect branch prediction is run across user mode or guest mode context switches to prevent user and guest mode from attacking other applications or virtual machines on the same host. In order to protect virtual machines from other virtual machines, ibpb_enabled=1 is needed even if ibrs_enabled is set to 2. If ibpb_enabled is set to 2, indirect branch prediction barriers are used instead of IBRS at all kernel and hypervisor entry points (in fact, this setting also forces ibrs_enabled to 0). ibpb_enabled=2 is the default on CPUs that don’t have the SPEC_CTRL feature but only IBPB_SUPPORT. ibpb_enabled=2 doesn’t protect the kernel against attacks based on simultaneous multi-threading (SMT, also known as hyperthreading); therefore, ibpb_enabled=2 provides less complete protection unless SMT is also disabled. This feature addresses CVE-2017-5715, variant #2.

Customer and vendors can disable the ibpb implementation in microcode by passing "noibpb" to the kernel command line at boot, or dynamically with the debugfs control below:

# echo 0 > /sys/kernel/debug/x86/ibpb_enabled

Das Fett markierte verstehe ich nicht richtig, vielleicht kann das jemand entschlüsseln. In welchem Fall muss SMT deaktiviert werden um den vollen Schutz zu bieten?

[unl34shed]

Mit ibpb_enabled=2 kannst du wohl immer noch Daten via SMT (Hyperthreading) auslesen und für einen besseren Schutz sollte man SMT auch deaktivieren.

Welcher Trick/Fehler dahinter steckt keine Ahnung.

[Complicated]

Schon klar. Was ich nicht verstehe ist auf welche CPUs das zutrifft ausgehend von den Default Settings oben. Sind das nun die Default Settings die nach dem Microcode Update aktiv sind? Ich kann mir nur schwer vorstellen, dass AMD SMT als einzige abschalten müssen bei neuen CPUs. So würde ich das in diesem Kontext interpretieren. Mir scheint hier ein Puzzleteil zu fehlen.

pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates
Diese beiden Zeilen erscheinen mir nur sinnvoll wenn sie umgekehrt wären - oben für ältere AMD CPUs da sie sowieso kein SMT haben und unten für die neuen mit SMT. Also als sei das Fett markierte vertauscht

[Gipsel]

Schon klar. Was ich nicht verstehe ist auf welche CPUs das zutrifft ausgehend von den Default Settings oben. Sind das nun die Default Settings die nach dem Microcode Update aktiv sind? Ich kann mir nur schwer vorstellen, dass AMD SMT als einzige abschalten müssen bei neuen CPUs. So würde ich das in diesem Kontext interpretieren. Mir scheint hier ein Puzzleteil zu fehlen.


Diese beiden Zeilen erscheinen mir nur sinnvoll wenn sie umgekehrt wären - oben für ältere AMD CPUs da sie sowieso kein SMT haben und unten für die neuen mit SMT. Also als sei das Fett markierte vertauscht
Oder AMD benötigt mit Zen kein IBRS (auch nicht mit SMT), wie der auf der letzten Seite verlinkte Artikel von arstechnica behauptet, weil man auf diese Art des Angriff nicht empfindlich ist.

[Complicated]

Tatsächlich auch so deutlich ausgeführt bei arstechnica- danke für den Hinweis:
Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address. This seems to be a product of good fortune; AMD switched to a different kind of branch predictor in Zen (like Samsung in its Exynos ARM processors, AMD is using simple neural network components called perceptrons), and the company happened to pick a design that was protected against this problem.
Gilt anscheinend auch für Samsungs Exynos. Ich kann mich noch an eine Diskussion erinnern zum Ryzen Launch über die "perceptrons", als mir jemand erklären wollte es sei das selbe an Technik das bisher auch benutzt wurde bei Sprungvorhersagen und es sei reines Marketing, dass AMD hier plötzlich über Verbesserungen durch AI/Machine Learning sprächen.

Damit ergibt das ein sinnvolles Gesamtbild.

[Setsul]

Bulldozer hatte auch schon perceptrons. Das heißt nicht, dass die beiden branch predictors identisch sind. Ändert auch nichts daran, dass AI/Machine Learning in dem Fall einfach Buzzwords sind, weil es sich besser anhört als "der branch predictor ist fast genauso wie der alte, nur etwas besser".

[Gipsel]

Das mit der Nutzung der vollen Adresse des Sprungs für den BTB ist der eigentlich wissenswerte Fakt in dem Abschnitt (deckt sich ja mit dem, was ich von Anfang an vermutet habe). Ein paar mehr wären aber noch interessant, um das besser einschätzen zu können (denn warum Zen kein IBRS benötigt, erklärt das nicht wirklich; es macht nur allgemein die Ausnutzung von Spectre v2 schwieriger).

[Dorn]

Irgendjemand hat sich aufgeregt das von Gigabyte nix kommt: :wink:

http://www.gigabyte.eu/Press/News/1586

(currently offers updates for models that support 6th/7th/8th generation Intel® Core™ processors and X99/X299 platform): https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html

[StefanV]

Could it get any worse?

YES; IT CAN!

https://www.reuters.com/article/us-cyber-security-intel/intel-says-patches-can-cause-reboot-problems-in-old-chips-idUSKBN1F101X

Intel Corp on Thursday said that recently issued patches for flaws in its chips could cause computers using its older Broadwell and Haswell processors to reboot more often than normal and that Intel may need to issue updates to fix the buggy patches.
Ähhm....

[Screemer]

Alles auf Win10 x64 1709. Beim normalen arbeiten merkt man nix, nutz den Laptop nur zum Surfen und Netflix.
Und dann opferst du Sicherheit für vielleicht 30 Sekunden Zeit? Richtige Entscheidung:up:

[Lehdro]

TIL random reboots sind ein Feature bei Intel.

[gedi]

Hat mal jemand Test mit Win 10 Build 17074 gemacht, denn da verkommt selbst ein 8700k@5G im Vergleich zum eigentlich gepatchten 17063 zur Krücke.

Beispiele:

Cinebench R15


17063: 1652P

17074: 1473P


3dK13, CPU-Score


17063: 22.5k

17074: 20.1k

[Complicated]

https://www.reuters.com/article/us-cyber-security-intel/intel-says-patches-can-cause-reboot-problems-in-old-chips-idUSKBN1F101X

Die Patches wurden ja teilweise zurück gezogen durch Intel. Detaillierte Infos gibt es z.B. bei Lenovo, siehe Beitrag #1337:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11602692#post11602692
Betroffen sind Broadwell, Haswell und Kaby Lake. Auch wenn Intel offiziell Kaby Lake nicht erwähnt:
https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

[Armaq]

Ich hoffe die Publikationen greifen das auf und nehmen sich Ende Januar die Zeit für eine Neubewertung der Marktlage. Intel hat das einfach verdient, sie wissen mindestens 6 Monate davon uns jetzt kommen lauter unreife Patches und noch unreiferes Verhalten dem Kunden und der Presse gegenüber.

[hq-hq]

man kann ja in Windows 10 die Updates 35 Tage aufschieben ^^

[Dr.Doom]

Und dann opferst du Sicherheit für vielleicht 30 Sekunden Zeit? Richtige Entscheidung:up:Nun, wenn er jeden Tag immer wieder alle seine Passwörter ändert für Netflix, die angesurften Webseiten (Amazon, Paypal, 3DC-Forum,...), Mail-Clients, Dropbox, Router und so weiter und so fort, dann ist die Gefahr ja auch gering.

[hq-hq]

schätze es reicht wenn er die youporns und crackfiles meidet :biggrin:

[lumines]

Nun, wenn er jeden Tag immer wieder alle seine Passwörter ändert für Netflix, die angesurften Webseiten (Amazon, Paypal, 3DC-Forum,...), Mail-Clients, Dropbox, Router und so weiter und so fort, dann ist die Gefahr ja auch gering.

Die meisten Sessions sind übrigens auch noch nach einer Passwortänderung gültig. Wenn jemand den gesamten Speicher auslesen kann, schnappt er sich einfach die Tokens etc. und kann dann lustig die Accounts weiterbenutzen, wenn der jeweilige Dienst nicht bei einer Passwortänderung alle Sessions ungültig macht. Gibt genug, die das nämlich nicht machen.

schätze es reicht wenn er die youporns und crackfiles meidet :biggrin:

Nope. Verstehe nie so ganz, was einige damit sagen wollen. Als ob man, wenn man ganz doll aufpasst, was man ansurft, irgendwie genug geschützt wäre. Schon haufenweise Newsseiten und ganz normale Werbenetzwerke haben Malware und Browser-Exploits verteilt. Selbst mitbekommen habe ich das z.B. bei watson.ch. Sogar mehrmals innerhalb von nur zwei Wochen.

Man patcht einfach und gut. Dann muss man auch keine Unterscheidung zwischen den Youporns und "seriösen" Webseiten vornehmen.

[Dorn]

Ich hoffe die Publikationen greifen das auf und nehmen sich Ende Januar die Zeit für eine Neubewertung der Marktlage. Intel hat das einfach verdient, sie wissen mindestens 6 Monate davon uns jetzt kommen lauter unreife Patches und noch unreiferes Verhalten dem Kunden und der Presse gegenüber.

Aber sowas von, Zeit genug war Ja für Aktien zu verkaufen.

[Dicker Igel]

Ja, man sollte einfach nicht wie der letzte Dau durch's Netz poltern.


Man patcht einfach und gut. Dann muss man auch keine Unterscheidung zwischen den Youporns und "seriösen" Webseiten vornehmen.
LOL ;D

[Complicated]

Für die meisten Kaby Lake Modelle werden neue Patches laut Lenovo erst ab dem 28.02. ausgeliefert.

[Complicated]

https://www.computerbase.de/2014-09/malware-ueber-werbung-von-doubleclick-und-zedo/
Erst Anfang September identifizierte Cisco Systems auf Amazon, YouTube und Yahoo Malvertising, welche den Nutzer auf infizierte Seiten weiterleiteten. Dabei greifen die Angreifer auf eine große Anzahl von Domains zurück, was die Wirksamkeit von auf Reputation basierenden Sicherheitslösungen stark einschränkt.Na wenn man Amazon, Youtube und Yahoo meidet... ;)

[Dicker Igel]

Eben, Junk via Ad geht überall. Wie gesagt, einfach nicht wie der letzte Dau agieren und man hat als Privatanwender auch ohne Patch keine Probleme. Die ganzen PW müssen auch erstmal im RAM liegen(und lange genug), damit der Schadcode sie auslesen kann. Wer dann die PW in einer PW.txt unter Dokumente hat, nujo ....

[StefanV]

Für die meisten Kaby Lake Modelle werden neue Patches laut Lenovo erst ab dem 28.02. ausgeliefert.
...möglicherweise mit starkem Performance hit??

[lumines]

Eben, Junk via Ad geht überall. Wie gesagt, einfach nicht wie der letzte Dau agieren und man hat als Privatanwender auch ohne Patch keine Probleme.

Du hast das ein bisschen missverstanden. Junk via Werbung kann überall reinkommen, also patcht man gegen die Lücke. Es gibt kein besonderes Verhalten, das dagegen schützen könnte. Außer du hörst generell auf, Code von Webseiten auszuführen, aber das dürfte wahrscheinlich für die meisten Nutzer nicht in Frage kommen.

Man kann jetzt natürlich darüber diskutieren, ob Spectre schon ausnutzbar ist. Wahrscheinlich ist es das nicht. Wenn noch kein Microcode-Update bereitsteht, sollte man nicht in Panik ausbrechen. Der einzige Unterschied zwischen einem DAU und nicht-DAU besteht aber darin, ob man patcht oder nicht. Alles andere ist Esoterik und schädlich.

Das ist so, als ob man sagen würde, dass intelligente Leute den Lümmel beim Sex schon rechtzeitig rausziehen, weil das zur Verhütung reicht. Der nicht-DAU weiß aber, dass man besser richtig verhüten sollte. Eine Auto-Analogie ist mir gerade nicht eingefallen.

Reboots und Co. wären natürlich unschön, aber die Performance-Unterschiede sind bei normaler Nutzung so gering, dass mich das nicht die Bohne interessiert. Da sind die Schwankungen bei normalen Treiberupdates meiner Grafikkarte ja fast größer.

[Complicated]

Der einzige Unterschied zwischen einem DAU und nicht-DAU besteht aber darin, ob man patcht oder nicht.
:up:

Es gab da mal eine Umfrage, die unterschied zwischen normalen PC Nutzern und sachkundigen ITlern was ihre Top 5 Massnahmen sind um ein System sicher zu machen, das Ergebnis ist sehr interessant. ITler haben Antivirus überhaupt nicht benannt und Patches an Nummer 1, während Normalos das Anitviren Programm ganz oben hatten und Patches überhaupt nicht aufzählten. Ich finde den Link gerade nicht.
Aber fefe hat auch eine schöne Anekdote dazu:
https://blog.fefe.de/?ts=a7f26258
Update: Und einen Punkt noch, den ich glaube ich im Blog noch nicht hatte, nur live beim Podium. Ich sage: Antiviren helfen nicht, ich setze keinen ein. Das Publikum sagt: Ja aber da kann man sich ja einen Virus einfangen.

Wir spulen eine Minute vor. Ich sage: Antiviren funktionieren nicht, weil Viren durchrutschen könnten. Das Publikum sagt: Tja 100% Sicherheit gibt es halt nicht.

Jetzt treten wir gemeinsam mal einen Meter zurück und schauen uns das an. Wieso ist das bei mir plötzlich ein Totschlag-Gegenargument, dass da vereinzelt mal was durchrutschen könnte (was ich im Übrigen auch so sehe und daher weitere Schutzmaßnahmen vorschlage), aber bei Antiviren ist das OK, wenn was durchrutscht? Anders formuliert: Wir ziehen mal auf beiden Seiten den Antivirus ab. Übrig bleibt bei beiden: Man muss sorgfältig sein, und gelegentlich könnte was was durchrutschen. Nur dass ihr für dieses Sicherheitsniveau Geld an die Schlangenölindustrie überweist und ich nicht. Oh und gucke mal: Das war genau meine These. Antiviren kosten Geld aber schaffen kein besseres Sicherheitsniveau.

[MadManniMan]

Mal kurz für Dummis wie mich: Ab welchen (kommenden) Architekturen sind wir hardware-safe vor Meltdown und Spectre?

[Freestaler]

Mal kurz für Dummis wie mich: Ab welchen (kommenden) Architekturen sind wir hardware-safe vor Meltdown und Spectre?

Vor Spectre V1 ist kein CPU sicher, dies muss per Software gelöst werden oder CPU als solches komplett geändert werden (was meiner Meinung nach nicht passieren wird)
Betreffend Meltdown und Spectre V2, entweder gepatched Intel Sys (inkl. neuem Bios und OS Ptach) oder AMD -> Also alles was kommt sollte da dann auch Safe sein, auch wenn @ Intel unter Umständen die Lücke ohne Biosfix und mit alten OS noch da "wäre". Wobei man ja ganz andere Sicherheitlücken hat, wenn man ein OS nutzt, welches nicht mehr gepatch wird z.B. ein Windows XP. Da sollte dann Meltdown das kleiner Übel sein.

[unl34shed]

weiß man noch nicht.
Dieses Jahr bei Intel wohl nicht, da man nur davon spricht mit neuen Chips den Software workaround zu erleichtern.

[robbitop]

Gibt es eine Möglichkeit den Patch zu deaktivieren? Ich zocke nur mit meinem PC und Sicherheit ist zweitrangig. Will keine Performanceinbußen.

[Dicker Igel]

Patches > AV ist klar. Aber Patches > Systemstabilität nicht. Davon ab hatte ich noch keinen Graka-Treiber, welcher sich 10% Leistung geschnappt hat und "Reboots und Co" halte ich nicht für "unschön", sondern für das Ergebnis von überhasteten Frickelwerk, welches ich mir ganz sicher nicht installiere.

[Armaq]

Gibt es eine Möglichkeit den Patch zu deaktivieren? Ich zocke nur mit meinem PC und Sicherheit ist zweitrangig. Will keine Performanceinbußen.
MS zwingt einen glaube ich dazu auf Win10. Apple released nur für HighSierra Patches.

[deekey777]

....

Der Ashampoo-Test sagt, dass mein x5-Z8350 weder gegen Spectre noch Meltdown abgesichert ist.

Gibt es dafür eine Erklärung, warum der Patch auf dem x5-Z8350 nicht aktiv ist?

[Rache Klos]

Gibt es eine Möglichkeit den Patch zu deaktivieren? Ich zocke nur mit meinem PC und Sicherheit ist zweitrangig. Will keine Performanceinbußen.

Du kannst den Patch KB4056892 deinstallieren, ich vermute aber mal, dass dies im nächsten großen Windows 10 Update fester Bestandteil sein wird. Dann hat man nur die Wahl, das Update nicht zu machen.

[Hobby]

- mit alter Hardware wär das nicht passiert = FX 8350 SCNR :wink:

[Poook]

Gibt es eine Möglichkeit den Patch zu deaktivieren? Ich zocke nur mit meinem PC und Sicherheit ist zweitrangig. Will keine Performanceinbußen.

Ich dachte beim zocken macht es keinen Unterschied?

[Dorn]

Ich dachte beim zocken macht es keinen Unterschied?
Meltdown hat keinen großen Einfluss aber Spectre (1&2) und da wiederum je nach Spiel extrem oder "akzeptabel"

Aber auf mein Gamingrechner werde ich kein Biosupdate gegen Spectre machen.

[Armaq]

Bisher sind es doch die BIOS Updates, welche wirklich Performance kosten.

[Pirx]

- mit alter Hardware wär das nicht passiert = FX 8350 SCNR :wink:
LOL wunderbar

[fondness]

Apple trifft es wohl besonders hart:
https://melv1n.com/iphone-performance-benchmarks-after-spectre-update/

[Screemer]

das was du da beschreibst ist einfach dummheit. man kann sichh ohne patch und biosupdate NICHT schützen. wieso kapieren das manche einfach nicht.

[Dicker Igel]

Na dann erzähle mir doch mal mit einfachen Worten, was mir ohne Patch jetzt so alles passiert und was Voraussetzung sein muss, damit überhaupt jemand auf Daten zugreifen kann und in welcher Zeitspanne. Aber in eigenen, einfachen Worten bitte, denn auf Copy/Paste Texte, oder entsprechende Links, kann ich gerne verzichten.

[mboeller]

Apple trifft es wohl besonders hart:
https://melv1n.com/iphone-performance-benchmarks-after-spectre-update/

hab ich im Apple iPhone Thread schon vor Tagen geposted... ist aber wahrscheinlich fake.

[Annator]

Apple trifft es wohl besonders hart:
https://melv1n.com/iphone-performance-benchmarks-after-spectre-update/

Das ist das Akku Problem nicht Meltdown/Spectre. Ist Fakenews.

https://browser.geekbench.com/v4/cpu/6395429

[mboeller]

Gibt es dafür eine Erklärung, warum der Patch auf dem x5-Z8350 nicht aktiv ist?

vielleicht ja deshalb:

https://www.heise.de/security/meldung/Meltdown-Patches-32-Bit-Systeme-stehen-hinten-an-3940207.html



Die c't-Redaktion hat diverse Installationsvarianten von Windows 7, Windows 8.1 und Windows 10 auf Intel-CPUs durchprobiert und dabei festgestellt, dass alle 32-Bit-Versionen bisher trotz Installation der Januar-Patches ungeschützt bleiben.


betrifft mich leider :(

vielleicht sehen deshalb auch einige keinen Unterschied vor/nach dem Patch

[Hunsrücker]

Bisher sind es doch die BIOS Updates, welche wirklich Performance kosten.

Da habe ich ja noch mal Glück gehabt! :biggrin:

[Ganon]

Bisher sind es doch die BIOS Updates, welche wirklich Performance kosten.

Ohne BIOS Update schalten die Systeme ihre Schutzmaßnahmen auch gar nicht an, weil sie es auch gar nicht können.

[Armaq]

Ohne BIOS Update schalten die Systeme ihre Schutzmaßnahmen auch gar nicht an, weil sie es auch gar nicht können.
Meltdown geht auch ohne BIOS-Update (wie gut kann ich nicht einschätzen).

[deekey777]

vielleicht ja deshalb:

https://www.heise.de/security/meldung/Meltdown-Patches-32-Bit-Systeme-stehen-hinten-an-3940207.html




betrifft mich leider :(

vielleicht sehen deshalb auch einige keinen Unterschied vor/nach dem Patch

Tolle Wurst.

(Genau den Artikel habe ich nicht gelesen. ;()

[Ganon]

Meltdown geht auch ohne BIOS-Update (wie gut kann ich nicht einschätzen).

Ja Meltdown. Aber Spectre Fixes gehen ohne BIOS Update nicht. Kein BIOS/Microcode Update -> keine Spectre (V2) Fixes -> kein weiterer Performance-Verlust. Das OS kann keine Instruktionen benutzen, die nicht da sind.

Wie man es dreht ist natürlich egal, da das Ergebnis identisch ist, aber das System wird langsamer, weil das OS die Spectre-Fixes überhaupt erst fahren kann.

[Darkman.X]

Gibt es eine Möglichkeit den Patch zu deaktivieren? Ich zocke nur mit meinem PC und Sicherheit ist zweitrangig. Will keine Performanceinbußen.

https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

To enable the fix *

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

Restart the computer for the changes to take effect.


To disable the fix *

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

Restart the computer for the changes to take effect.


* Note setting of 3 is accurate for both enable/disable settings due to masking.

[deekey777]

- mit alter Hardware wär das nicht passiert = FX 8350 SCNR :wink:
Kannst du den Trick erklären?

[Vortex]

Hallo,

bei mir funktioniert seltsamerweise das Tool von Ashampoo nicht, wenn ich auf "Start" klicke prüft es das System kommt aber zu keinem Ergebnis, ich habe es schon bis zu 30 Minuten! laufen lassen, aber nichts. Das PowerShell-Script von Microsoft läßt sich nicht installieren weil Windows nach der Eingabe von: Install-Module SpeculationControl blöderweise nachfragt, mit welchen Programm die Datei geöffnet werden soll? Auch das Ändern der SecurityPolicy mittels Set-ExecutionPolicy RemoteSigned -Scope Currentuser behebt das Problem nicht. Auch Specucheck habe ich bereits ausprobiert, welches mir aber nur anzeigt das kein Patch installiert ist, den ich mangels Angreifbarkeit von Ryzen über Meltdown ja auch nicht benötige. Weiß jemand Rat?

[Birdman]

Install-Module SpeculationControl blöderweise nachfragt, mit welchen Programm die Datei geöffnet werden soll?
https://www.microsoft.com/en-us/download/details.aspx?id=54616 installieren, dann klappts auch mit dem Install-Module command.

[Complicated]

Das PowerShell-Script von Microsoft läßt sich nicht installieren weil Windows nach der Eingabe von: Install-Module SpeculationControl blöderweise nachfragt, mit welchen Programm die Datei geöffnet werden soll?
Den selben Fall haben wir hier: http://www.planet3dnow.de/vbulletin/threads/429296-Meltdown-Spectre-Powershell-Verifikation-Windows-7
mit dem User "Pinnacle Ridge" gehabt. Da hat auch das 5.1 Framework nicht geholfen und wir konnten bisher keine Lösung finden. Die Vermutung geht dahin, dass es ein grundsätzliches Problem mit der Windows Installation ist. Solltest du dahinter kommen was es war wäre eine PN oder ein Posting im dortigen Thread sehr willkommen. Danke.

[Dr.Doom]

Ich hab' einfach den Skript-Text in eine geöffnete PowerShell-Konsole kopiert und dann das Kommando ("Get-..") abgesetzt... :freak:

[Complicated]

Die Installation des Moduls ist dort ebenfalls geglückt, nur bei der Ausführung des "Get-SpeculationControlSettings" wird immer der "Datei Öffnen" Dialog geöffnet und das Script nicht ausgeführt. Hier stimmen irgendwelche Registrierungen aus irgendeinem Grund nicht.

[Vortex]

Hallo,

der Tipp aus dem Forum von Planet 3dNow! die nuget.exe manuell herunterzuladen und in den Ordner C:\Program Files\PackageManagement\nuget\nuget.exe zu kopieren hat funktioniert. Nach der Eingabe von Install-Module SpeculationControl wurde nuget durch die PowerShell installiert und das Script läuft. Das Tool von Ashampoo funktioniert jetzt auch, es bedient sich ja der selben Vorgehensweise wie das Script von Microsoft. Der User "Pinnacle Ridge" war ja soweit das das Modul installiert wurde, aber er kann die Settings nicht abrufen. Keine Ahnung warum das so ist.

[Hobby]

Kannst du den Trick erklären?

Grafikspielchen mit "Paintshop Pro" ...

[Noebbie]

Da ich ja geschimpft hatte, dass Gigabyte sich nicht zu Wort meldet, hier der Nachtrag:

Mittlerweile haben sie eine Seite mit den entsprechenden Boards ins Netz gestellt:

https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html

Falls die News schon da war, sorry. Ansonsten: Gerne.

[Blutmaul]

Da ich ja geschimpft hatte, dass Gigabyte sich nicht zu Wort meldet, hier der Nachtrag:

Mittlerweile haben sie eine Seite mit den entsprechenden Boards ins Netz gestellt:

https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html

Falls die News schon da war, sorry. Ansonsten: Gerne.

Bitte, gerne, im Intel-MB-Forum und hier im Thread tauchte es auch schon auf. :)

[Screemer]

8700k - Mainboard BIOS noch nicht angepasst, Windows 10 Build 17074


http://up.picr.de/31525577yc.jpg

System: 8700k@5G, Asus Maximus X Hero - Bios 1003

Ich denke die Build 17074 stopft die Lücke. Da in 17074 auch das Store-Problem gefixt ist, bleibt es jedem selbst überlassen die Insider-Build mal auszuprobieren.

Da sieht mal wieder was solche Tools teils für bullshkt ausgeben. Ohne bios kein komplettes Spectre fix.

Das mus hier auch rein

[Vortex]

Sind die alten Athlon XP "Barton" eigentlich auch anfällig für Spectre? Hier: https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/2/ ist der Athlon XP nicht gelistet, weil zu alt. Ich habe noch einen XP 1500+ der mit Windows 10 x64 und 1,5 GB Ram zufriedenstellend flott läuft, so für`s Online-Banking und Co. wäre der noch brauchbar. Aber ich gehe sehr stark davon aus das die alten Athlon XP auch betroffen sind, soll ja jede CPU seit 1995 betreffen.

[Freestaler]

Das mus hier auch rein

Aashampoo spectre check also unbrauchbar, da ja bios update fehlt?

[dildo4u]

Sind die alten Athlon XP "Barton" eigentlich auch anfällig für Spectre? Hier: https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/2/ ist der Athlon XP nicht gelistet, weil zu alt. Ich habe noch einen XP 1500+ der mit Windows 10 x64 und 1,5 GB Ram zufriedenstellend flott läuft, so für`s Online-Banking und Co. wäre der noch brauchbar. Aber ich gehe sehr stark davon aus das die alten Athlon XP auch betroffen sind, soll ja jede CPU seit 1995 betreffen.
Ich würde es so oder so lassen da 32 Bit OS scheinbar keine Funktionierenden Updates bekommen haben.

https://www.heise.de/security/meldung/Meltdown-Patches-32-Bit-Systeme-stehen-hinten-an-3940207.html

[x-force]

bitte die security diskussion auslagern, wenn das ein mod liest.


Junk via Werbung kann überall reinkommen, also patcht man gegen die Lücke. Es gibt kein besonderes Verhalten, das dagegen schützen könnte. Außer du hörst generell auf, Code von Webseiten auszuführen, aber das dürfte wahrscheinlich für die meisten Nutzer nicht in Frage kommen.


du präsentierst die lösung doch selbst, wie kannst du da davon reden, daß es keine möglichkeiten gibt?

wer sich dafür zu bequem ist, muss halt mit der minderperformance leben.
das ist schon etwas einseitig dargestellt.
wer werbung nicht blockt gehört sowieso bestraft.
dann könnte man sich ja auch gleich überall tracken lassen.

@screemer du wähnst dich also in sicherheit, weil du ein softwareupdate in verbindung mit einem biosupdate eingespielt hast?
vllt wirst auch du auf deinem hohen ross irgendwann mit der realität konfrontiert und stellst fest, daß es keine absolute sicherheit gibt und 99% aller infekte nur auftauchen, weil das problem vor dem bildschirm sitzt.

ich nehme an, du hast die intel me selbständig deaktiviert? ;)

ich halte es für wesentlich dümmer sich zu unrecht sicher zu fühlen

[Vortex]

@dildo4u

Mein Fehler, ich hatte ja Windows 10 x32 installiert, nicht x64. Das hatte ich vergessen, die Kiste habe ich das letzte mal vor gut 2 Jahren mal gebootet. Dann hat es keinen Zweck.

[yummy_candy]

Die Installation des Moduls ist dort ebenfalls geglückt, nur bei der Ausführung des "Get-SpeculationControlSettings" wird immer der "Datei Öffnen" Dialog geöffnet und das Script nicht ausgeführt. Hier stimmen irgendwelche Registrierungen aus irgendeinem Grund nicht.


Save-Module -Name SpeculationControl
C:\Windows\System32\WindowsPowerShell\v1.0\Modules (the Path)
Set-Location C:\Windows\System32\WindowsPowerShell\v1.0\Modules
Set-ExecutionPolicy Unrestricted
Import-Module SpeculationControl
Set-ExecutionPolicy Restricted
Get-SpeculationControlSettings

https://www.reddit.com/r/PowerShell/comments/7o8nee/powershell_cmdlets_prompt_how_do_you_want_to_open/

Hat bei mir funktioniert.

[Screemer]

@screemer du wähnst dich also in sicherheit, weil du ein softwareupdate in verbindung mit einem biosupdate eingespielt hast?
vllt wirst auch du auf deinem hohen ross irgendwann mit der realität konfrontiert und stellst fest, daß es keine absolute sicherheit gibt und 99% aller infekte nur auftauchen, weil das problem vor dem bildschirm sitzt.

ernsthaft? :facepalm:

[gravitationsfeld]

Das ist leider eine gaengige Meinung:
https://sdtimes.com/wp-content/uploads/2015/07/0723.sdt-google-security.png

Updates schaffen nicht mal die Top 5 bei Usern.

[mboeller]

wer werbung nicht blockt gehört sowieso bestraft.
dann könnte man sich ja auch gleich überall tracken lassen.


ich hoffe du hast Autofill dann auch deaktiviert?

https://www.heise.de/security/meldung/Tracking-Skripte-klauen-E-Mail-Adressen-aus-Web-Browsern-3931772.html

das wird inzwischen auch als "cookie" eingesetzt.
Beim Firefox funktioniert das aber nicht.

[Lurtz]

Die bisherigen Mitigations in Browsern scheinen praktisch wirkungslos zu sein:
Research showed that microarchitectural attacks like cache attacks can be performed through websites using JavaScript. These timing attacks allow an adversary to spy on users secrets such as their keystrokes,leveragingfine-grainedtimers. However,theWCandbrowser vendors responded to this significant threat by eliminating fine-grained timers from JavaScript. This renders previous high-resolution microarchitectural attacks non-applicable. We demonstrate the inecacy of this mitigation by finding and evaluating a wide range of new sources of timing information. We develop measurement methods that exceed the resolution of ocial timing sources by to orders of magnitude on all major browsers, and even more on Tor browser. Our timing measurements do not only re-enable previous attacks to their full extent but also allow implementing new attacks. We demonstrate a new DRAM-based covert channel between a website and an unprivileged app in a virtual machine without network hardware. Our results emphasize that quick-fix mitigations can establish a dangerous false sense of security.
Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript (https://gruss.cc/files/fantastictimers.pdf)

Vielleicht hat Google die Mitigations deshalb nicht ausgeliefert?

[mboeller]

Die bisherigen Mitigations in Browsern scheinen praktisch wirkungslos zu sein:

Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript (https://gruss.cc/files/fantastictimers.pdf)

Vielleicht hat Google die Mitigations deshalb nicht ausgeliefert?

betrifft ja "nur" den Firefox. Chrome benutzt ja "Strict Site Isolation" als mitigation.

[Ganon]

Vielleicht hat Google die Mitigations deshalb nicht ausgeliefert?

https://www.chromium.org/Home/chromium-security/ssca


In line with other browsers, Chrome has disabled SharedArrayBuffer on Chrome 63 starting on Jan 5th, and will modify the behavior of other APIs such as performance.now, to help reduce the efficacy of speculative side-channel attacks. This is intended as a temporary measure until other mitigations are in place.

Sie haben das Gleiche gemacht wie alle anderen Browser auch. Nur die Mitigations im JavaScript Compiler selbst kommen erst mit Chrome 64 und danach noch weitere.

[Rancor]

Wenn man es denn aktiviert. Das werden wohl nur die wenigsten tun.
Viel schlimmer finde ich das ältere CPUS wie Sandy, Ivy Bridge und Haswell keine Updates erhalten. Das ist ziemlich skandalös.

[Ganon]

Viel schlimmer finde ich das ältere CPUS wie Sandy, Ivy Bridge und Haswell keine Updates erhalten. Das ist ziemlich skandalös.

Mal abgesehen davon, dass mein Haswell scheinbar schon ein Update hat, ist mein letzter Stand:

Intels CEO Brian Krzanich hat in seiner Keynote auf der Elektronikmesse CES in Las Vegas bekräftigt, dass alle Intel-Chips der vergangenen fünf Jahre Updates gegen Meltdown und Spectre "innerhalb einer Woche" bekommen sollen. Die restlichen betroffenen Chips sollen demnach bis Ende Januar einen Microcode-Fix bekommen.

Hat sich daran bisher was geändert?

[Lurtz]

In addition to reviving attacks that were now deemed infeasible, we demonstrated the first DRAM-based side channel in JavaScript. In this side-channel attack, we implemented a covert channel between an unprivileged binary in a VM with no network interface and a JavaScript program in a browser outside the VM, on the same host.

Das ist so übel :freak: :(

betrifft ja "nur" den Firefox. Chrome benutzt ja "Strict Site Isolation" als mitigation.
Das betrifft Gecko, EdgeHTML, Webkit...

Und in Chrome läuft es bisher nur wenn man die Flag setzt.

https://www.chromium.org/Home/chromium-security/ssca

Sie haben das Gleiche gemacht wie alle anderen Browser auch. Nur die Mitigations im JavaScript Compiler selbst kommen erst mit Chrome 64 und danach noch weitere.
Ok, hätte mich auch gewundert. Wird dann natürlich wieder völlig falsch dargestellt...

[Rancor]

Mal abgesehen davon, dass mein Haswell scheinbar schon ein Update hat, ist mein letzter Stand:



Hat sich daran bisher was geändert?

ASUS patch nur 6th 7th und 8th Generation. Ebenso MSI. Das ist aktueller Stand. Afaik wollte Intel auch nur die CPUs der letzten 5 Jahren patchen. Haswell müsste da ja noch bei sein.

Edit: Ahh ok. ich wusste nicht das der rest noch kommen soll.

Edit 2: https://newsroom.intel.com/news-releases/security-first-pledge/

Hier steht es etwas anders. :freak: Demnach stehen für bis zu 90% der 5 Jahren alten CPUs Updates zum Ende der Woche ( letzte Woche also ) zur Verfügung. Der Rest wird bis Ende Januar gepatcht. Danach schaut man sich ältere Produkte an. Ob da was passiert ist nicht klar.

[Ganon]

ASUS patch nur 6th 7th und 8th Generation. Ebenso MSI.

Es besteht prinzipiell die Möglichkeit, dass du den Microcode in deinem BIOS selbst aktualisierst, aber ich habe damit mangels Notwenigkeit auch keine Erfahrung.

Aber es mir auch durchaus klar, dass die meisten Leute diese Updates nie sehen werden. Aber das ist ja nun leider auch nichts Neues in der Consumer-Welt. *gucktmalfixzuAndroidrüber*


Hier steht es etwas anders. :freak: Demnach stehen für bis zu 90% der 5 Jahren alten CPUs Updates zum Ende der Woche ( letzte Woche also ) zur Verfügung. Der Rest wird bis Ende Januar gepatcht. Danach schaut man sich ältere Produkte an. Ob da was passiert ist nicht klar.

Ja, da steht es etwas anders, aber auch nicht "es wird gar nicht gepatcht". Man wird halt vermutlich eher die alten CPUs zuerst fixen die bei Großkunden noch so im VM Einsatz sind.

[unl34shed]

Edit 2: https://newsroom.intel.com/news-releases/security-first-pledge/

Hier steht es etwas anders. :freak: Demnach stehen für bis zu 90% der 5 Jahren alten CPUs Updates zum Ende der Woche ( letzte Woche also ) zur Verfügung. Der Rest wird bis Ende Januar gepatcht. Danach schaut man sich ältere Produkte an. Ob da was passiert ist nicht klar.

Richtig lesen!
Bis Ende Januar werden die restlichen 10%, der in den letzten 5 Jahren veröffentlichten Prozessoren, mit Updates versorgt.

Bei älteren schließen sie es zwar nicht komplett aus, es wird aber nach "Kundenanfrage" Prioritäten verteilt.

[Complicated]

Intels CEO Brian Krzanich hat in seiner Keynote auf der Elektronikmesse CES in Las Vegas bekräftigt, dass alle Intel-Chips der vergangenen fünf Jahre Updates gegen Meltdown und Spectre "innerhalb einer Woche" bekommen sollen. Die restlichen betroffenen Chips sollen demnach bis Ende Januar einen Microcode-Fix bekommen.Hat sich daran bisher was geändert?
Ja:
https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

Mehr Infos bei Lenovo:
https://support.lenovo.com/de/de/solutions/len-18282
Withdrawn CPU Microcode Updates: Intel provides to Lenovo the CPU microcode updates required to address Variant 2, which Lenovo then incorporates into BIOS/UEFI firmware. Intel recently notified Lenovo of quality issues in two of these microcode updates, and concerns about one more. These are marked in the product tables with “Earlier update X withdrawn by Intel” and a footnote reference to one of the following:
*1 – (Kaby Lake U/Y, U23e, H/S/X) Symptom: Intermittent system hang during system sleep (S3) cycling. If you have already applied the firmware update and experience hangs during sleep/wake, please disable sleep (S3) mode on your system, and then apply the improved update when it becomes available. If you have not already applied the update, please wait until the improved firmware level is available.
*2 – (Broadwell E) Symptom: Intermittent blue screen during system restart. If you have already applied the update, Intel suggests continuing to use the firmware level until an improved one is available. If you have not applied the update, please wait until the improved firmware level is available.
*3 – (Broadwell E, H, U/Y; Haswell standard, Core Extreme, ULT) Symptom: Intel has received reports of unexpected page faults, which they are currently investigating. Out of an abundance of caution, Intel requested Lenovo to stop distributing this firmware.
Im Link folgt dann eine Liste der einzelnen Produkte. So werden Kaby Lake CPUs erst zum 28.02 mit neuen BIOS Versionen beliefert laut Tabelle. Und andere gar erst am 31.3.2018.

[MadCat]

Hi,

von dem zurückgezogenen Update sind auch die dienstlichen T440p betroffen, welche ich erst vor kurzem mit dem genannten Update betankt habe.
Lt. MS-Powershell-Testscript gab es keinen unterschied zu vorher - wahrscheinlich der Grund für die Rücknahme... >_>
Warten bis zum 31.3.

[lumines]

du präsentierst die lösung doch selbst, wie kannst du da davon reden, daß es keine möglichkeiten gibt?

wer sich dafür zu bequem ist, muss halt mit der minderperformance leben.
das ist schon etwas einseitig dargestellt.
wer werbung nicht blockt gehört sowieso bestraft.
dann könnte man sich ja auch gleich überall tracken lassen.

Werbung ist eine Art, wie Spectre ausgenutzt werden könnte, aber eben nicht nur. Es könnte auch über ein JS-Skript ausgenutzt werden, das du vorher einmal in NoScript freigegeben hast, das aber modifiziert wurde und jetzt ein anderes Skript ausliefert. Ich habe mir NoScript nie genau angeguckt, aber mich würde wundern, wenn es da irgendwelche Prüfsummen erstellt und jedes Mal bei Änderungen neu fragt.

Natürlich wollen wir glauben, dass man sich mit dem richtigen Verhalten schützen kann, weil das eben so unsere Reaktion auf alles in der physischen Welt ist. Hab genug Erfahrung, sei kein Dummkopf und alles wird gut. Die Dummen sterben zuerst. Weiß doch jedes Kind.

Leider lassen sich solche Weisheiten aber nicht auf Exploits wie für Spectre übertragen. Du kannst den Angriffsvektor eliminieren (keine JS-Skripte oder generell keinen dynamisch nachgeladenen Code von Dritten ausführen), aber damit geht dir viel verloren. Gerade JS wird haufenweise benutzt, ohne dass man das direkt merkt. Alleine zu dokumentieren, an welchen Stellen überall JS in einem Desktop-OS benutzt wird, wäre ein Vollzeitjob. Es ist schlicht nicht praktikabel. Heute kann praktisch überall JS eingebettet sein. Grundsätzlich ist das auch nicht schlimm, weil man bisher JS gut im Griff hatte, aber durch Spectre muss man eben vieles neu bewerten. Man kommt um Patches nicht herum.

[scully1234]

Hab das mal korrigiert für dich, und in ein paar Wochen ,wenn sich der Schleier gelüftet hat, kommen wir auf die Aussage zurück

Spectre war vor kurzen auch noch kein Thema bei AMD...


Da brauchst du nichts korrigieren, von allen bekannten Sicherheitslücken trifft AMD nur Spectre V1.


AMD musste nun einräumen, dass seine Hauptprozessoren offenbar doch wesentlich anfälliger für die zweite Variante des Angriffsszenarios Spectre sind (CVE-2017-5715, Branch Target Injection) sind als bislang gedacht. Dies gab AMDs Senior Vice President Mark Papermaster in einer aktualisierten Sicherheitsinformation auf der AMD-Website bekannt (https://www.heise.de/newsticker/meldung/AMD-rudert-zurueck-Prozessoren-doch-von-Spectre-2-betroffen-Microcode-Updates-fuer-Ryzen-und-Epyc-in-3939975.html?wt_mc=rss.ho.beitrag.rdf)

vielleicht das nächste mal doch erstmal abwarten bevor man irgend was als Faktum präsentiert:wink:

mal sehen was noch so raus kommt in nächster Zeit...

[Rancor]

Richtig lesen!
Bis Ende Januar werden die restlichen 10%, der in den letzten 5 Jahren veröffentlichten Prozessoren, mit Updates versorgt.

Bei älteren schließen sie es zwar nicht komplett aus, es wird aber nach "Kundenanfrage" Prioritäten verteilt.

Nicht anderes habe ich gesagt :confused:

vielleicht das nächste mal doch erstmal abwarten bevor man irgend was als Faktum präsentiert:wink:

Du brauchst dich garnicht freuen, das du AMD wieder einen reinwürgen kannst. Es wurde hier schon einige Seiten vorher diskutiert und die Darstellung von heise ist sachlich falsch.
Spectre 2 ist auf AMD CPUs nur theoretisch möglich. Ein Angriff hat aber noch nicht geklappt. Es wird ein optionales Update geben damit es wohl unmöglich wird. Gispel kann da mehr zu sagen.

[unl34shed]

Nicht anderes habe ich gesagt :confused:.

Hast Recht, da hab ich was falsches gelesen... Sorry

[scully1234]

.
Spectre 2 ist auf AMD CPUs nur theoretisch möglich. Ein Angriff hat aber noch nicht geklappt. .
Ist doch völlig egal wie das Pferd heißt,es wurde behauptet Spectre V2 ist AMD außen vor, und das stimmt nun mal nicht mehr Stand heute

Reinwürgen ohne Verstand wollte am Anfang auch jeder Intel eine, und nun ist das Ausmaß viel größer, und alle sitzen sie mit im Boot

[Complicated]

AMD hat zu diesen falschen Darstellungen, wie sie auch heise verbreitet, klar Stellung bezogen:
https://www.reuters.com/article/brief-amd-says-no-change-to-cos-position/brief-amd-says-no-change-to-cos-position-on-susceptibility-to-gpz-variant-1-or-gpz-variant-2-idUSFWN1P60X7
* AMD SAYS THERE IS NO CHANGE TO AMD’S POSITION ON OUR SUSCEPTIBILITY TO GPZ VARIANT 1 OR GPZ VARIANT 2 (COLLECTIVELY CALLED SPECTRE IN NEWS REPORTS)

* AMD- SPECTRE VARIANT 2 NOT DEMONSTRATED TO WORK ON AMD PRODUCTS; OUT OF CAUTION, MAKING OPTIONAL MICRO CODE UPDATES AVAILABLE TO FURTHER CONTAIN THREAT*
https://www.hardocp.com/news/2018/01/11/amd_doubles_down_on_previous_spectre_meltdown_statments
* The update in relation to Variant 2 is that even though Variant 2 has not been demonstrated to work on AMD products due to differences in our micro architecture, out of an abundance of caution we are making optional micro code updates available to further contain the threat.

[HotSalsa]

Hab mal mein iPhone 7 Plus mit Geekbench getestet.

Der Score ist nach dem Fix in 11.2.2 sogar etwas nach oben gegangen. Scheint also auf dem iPhone performancemässig keinen Einfluss zu haben.

[Dicker Igel]

ernsthaft? :facepalm:
Ich warte auch noch auf eine "Antwort". (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11603686&postcount=1400)

[Rancor]

Ist doch völlig egal wie das Pferd heißt,es wurde behauptet Spectre V2 ist AMD außen vor, und das stimmt nun mal nicht mehr Stand heute

Reinwürgen ohne Verstand wollte am Anfang auch jeder Intel eine, und nun ist das Ausmaß viel größer, und alle sitzen sie mit im Boot

Sie haben von Anfang an gesagt, das für Spectre 2 "near zero risk" besteht und dabei bleiben Sie. Keine Ahnung was du konstruieren willst?
Heise berichtet falsch.

[scully1234]

The update in relation to Variant 2 is that even though Variant 2 has not been demonstrated to work on AMD products due to differences in our micro architecture, out of an abundance of caution we are making optional micro code updates available to further contain the threat.

Na da kann sich ja jetzt jeder sicher zurücklehnen ,weil der Angriff "bisher" noch nicht funktioniert hat:freak:

Wie lange haben sie nochmal bei Intel benötigt um nen Angriffsvector zu finden?...

"das ging auch von heute auf morgen"

Wenn das doch nur theoretisch funktioniert, wieso dann das Update ?

Fragen über Fragen

[Rancor]

Also dir muss schon richtig einer abgehen, wenn du gegen AMD keifen kannst oder? Meine Güte. Ließ dich ein und dann wirst du sehen warum spectre 2 auf AMD CPUs nicht so funktionieren kann wie auf Intel CPUs. Ein theoretische Restrisiko besteht ja...

Jetzt wissen wir auch, warum AMD für Spectre v2 von einem nur kleinem Risiko der Ausnutzung ausgeht. Wie hier im Thread schon vermutet, speichern die im Branch Target Buffer nicht nur ein paar Bits der Adresse (wie intel) sondern deutlich mehr, nämlich offenbar die komplette Adresse. Um den BTB zu "vergiften" muß man also Code an exakt der gleichen Adresse ausführen wie der angegriffene Code (was wegen virtuellem Speicher im Prinzip geht, solange dort im BTB keine physischen Adressen abgelegt sind [AMD hat seit Ryzen den ITLB im Branch prediction-Pfad, also hmm]). Das macht es tatsächlich schwieriger.

Aber theoretisch kannst du auch mit 99% der Lichtgeschwindigkeit fliegen... praktisch nur nicht.

Fakt ist das AMD nicht zurückrudert ist oder Bullshit erzählt hat. Sie haben von Anfang an gesagt es bestehe near zero risk und dabei ist es bis heute geblieben. Sie haben sich nur dazu entschieden ein OPTIONALES Update herauszubringen..

[Screemer]

Ich warte auch noch auf eine "Antwort". (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11603686&postcount=1400)
Hier im Thread gibts Erklärung in geekspeech und in boonspeech. Einfach bisschen lesen. Es ist müßig alles zigfach zu wiederholen.

[lumines]

Ich warte auch noch auf eine "Antwort". (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11603686&postcount=1400)

Du wirst keine Antwort bekommen, weil es unmöglich ist alle möglichen Angriffszenarien individuell durchzuspielen. Sobald man sich auf das Terrain begibt, hat man schon verloren.

Das ist in etwas so, wie wenn jemand fragen würde, warum man sich im Auto anschnallen sollte. Es gibt sicher genug Leute da draußen, die noch nie einen Unfall hatten, bei dem der nützlich gewesen wäre. Im Grunde ist es im alltäglichen Verkehr eine relativ abstrakte Gefahr. Man hat schließlich nicht jeden Tag einen Unfall.

Man will einfach die ganze Klasse von Unfällen abmildern, die passieren, wenn man irgendwo gegenfährt. Es gibt da einen Konsens, dass man gar nicht austesten will, was passieren würde, wenn man den Gurt weglässt und schnallt sich einfach an. Man kann schließlich nie an alle Szenarien denken. Anstatt zig Szenarien durchzuspielen, wie und wann man einen Gurt theoretisch vermeiden könnte, hat man das so einfach akzeptiert, weil es schlicht für den Fall, wenn doch einmal etwas passiert, keine Rolle spielt. Sobald man versucht alle Szenarien aufzuzählen, erhält man nur Quatsch, weil es nicht möglich und auch nicht zielführend ist. Man hat in vielen Fällen keinen Einfluss auf seine Umgebung und exakt das ist eben auch das Problem mit Spectre.

Man kann im Straßenverkehr aufpassen und das ist auch gut. Genau so kann man schädliche Werbung blocken, kein Thema. Aber was machst du, wenn jemand anderes im Straßenverkehr nicht aufpasst? Oder bei Spectre: Wie willst du die Exploits verhindern, wenn ein ehemals als "sicher" eingestufter Webserver gehackt wird und dir schädlichen Code ausliefert? Beim Auto schnallst du dich an, bei Spectre patchst und aktivierst du eben alles, was die Chance der Ausnutzung stark abmildert. Nicht alles lässt sich dadurch verhindern, dass man gut aufpasst.

[BlackBirdSR]

Kurze Frage ohne viel Zeit zum nachlesen bisher...
Wie bekomme ich Updates für i2700 und z68?

[Rancor]

Derzeit unbekannt wann und vor allem Ob es Updates für Sandy Bridge geben wird.

[StefanV]

Das ist leider eine gaengige Meinung:
https://sdtimes.com/wp-content/uploads/2015/07/0723.sdt-google-security.png

Updates schaffen nicht mal die Top 5 bei Usern.
...weswegen sogar die Leute vom CCC (Ron + fefe) inzwischen auch automatische Updates ohne Wissen des Users empfehlen.
Weil die User einfach zu unfähig sind, das selbst zu machen...

Und ich vertrete inzwischen auch die Meinung, dass automatische Updates der Standard sein sollte - auch bei Linux.
Aber da denkt man halt nicht an die Oma und andere Technik Analphabeten, die keinen Plan von Updates haben...

[Ganon]

Generell (zumindest bei allem <Skylake) funktionieren Googles Retpoline Patches auch ohne BIOS Update. Es ist scheinbar auch noch gar nicht so ganz klar was nun auf lange Sicht so zum Einsatz kommt. Alles was bis jetzt passiert ist, sind ja mehr so schnelle Reaktionen damit man überhaupt was hat.

Auf der einen Seite hat man bisher einen reinen Software-Fix (Retpoline), der aber nicht bei allen CPUs funktioniert und auf der anderen Seite einen Hardware-Fix (Microcode + Software-Anpassung), der nicht bei allen CPUs vorhanden ist. Wie genau das alles nachher im Kernel und im Userspace "allgemein" gehandhabt werden soll ist auch noch gar nicht so klar.

[Complicated]

...weswegen sogar die Leute vom CCC (Ron + fefe) inzwischen auch automatische Updates ohne Wissen des Users empfehlen.
Weil die User einfach zu unfähig sind, das selbst zu machen...

Und ich vertrete inzwischen auch die Meinung, dass automatische Updates der Standard sein sollte - auch bei Linux.
Würden Updates selber keine Probleme bereiten, wäre das wahrscheinlich auch schon längst so. Nur es passiert halt viel zu oft, dass danach die Rechner nicht mehr machen was sie sollen. Auch aktuell gab es ja wieder solche Fälle.

[Dicker Igel]

lumines,

das ist für mich keine zufriedenstellende Antwort auf meine Frage. Ich will wissen, wer mich jetzt dadurch angreifen kann, wie er das genau macht und warum das nicht schon in den vergangen 10 Jahren passiert ist. Allein für die Mukke (http://abload.de/image.php?img=043587sr3.jpg) habe ich 3 betroffene Systeme, wobei da nur ein Desktop mit 2600k online ist. Patche ich das alles, hab ich weniger Leistung(da hängen quasi alle Tools am CPU!) und wohlmögliche instabile Systeme, die mir während 'ner Session um die Ohren fliegen. Das steht hier in keinem rationalen Verhältnis - sorry.

[LadyWhirlwind]

Die bisherigen Mitigations in Browsern scheinen praktisch wirkungslos zu sein:

Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript (https://gruss.cc/files/fantastictimers.pdf)

Vielleicht hat Google die Mitigations deshalb nicht ausgeliefert?

Lösen wird man das wohl nur können, in dem man die Prozessorarchitektur grundsätzlich überdenkt. Möglicherweise muss man dazu sogar x86 anpassen.

[Angiesan]

Nur zur Info, da man oft von fehlendem Support lesen muss:
----------------------------------------------------------------------------------------
vielen Dank für Ihre Anfrage.

Es wird ein neues BIOS Update geben für Ihr Mainboard.
Bis das BIOS bereitgestellt werden kann, wird es ca. 3 bis 4 Wochen dauern.
Für die Intel 8/9 und X99 Chipsätze wird es demnächst neue Mikrocode Version geben, welche dann in neue BIOS Files eingebunden werden.

Die passende BIOS Datei können sie dann auf der MSI Seite runter laden.
Rufen Sie dazu die Produkt Seite zu Ihrem Mainboard auf.

Eine Anleitung zum BIOS Update finden Sie hier:

Anschließend kopieren Sie das BIOS auf einen USB Stick, dieser muss FAT32 Formatiert sein.
Bitte die Bios Datei muss im Hauptverzeichnis liegen und darf nicht in einem Ordner abgelegt werden.
Dann bitte das BIOS aufrufen und dort Bios Update auswählen um das neuste BIOS aufzuspielen.
Der USB Stick sollte direkt an einem USB 2.0 Port hinten am Mainboard angeschlossen werden, nicht an einem Front Panel.
(Bei älteren Mainboard gibt es die Auswahl BIOS mit ME Update)

Als Hinweis, BIOS mit ME update gibt es nur bei Intel Mainboards.

Mit freundlichen Grüßen
Ihr MSI Tech. Support Team

------------------------------------------------------------------------------------
Das hier verbaute Mainboard ist ein Z87M Gaming mit einer Xeon E3 1230 V3 also ein Haswell-Ws CPU..........Ich finde es super von MSi :up:auch Boards zu bedienen die 4 Jahre auf dem Buckel haben.

[lumines]

das ist für mich keine zufriedenstellende Antwort auf meine Frage. Ich will wissen, wer mich jetzt dadurch angreifen kann, wie er das genau macht und warum das nicht schon in den vergangen 10 Jahren passiert ist.

Du wirst darauf auch nie eine zufriedenstellende Antwort erhalten. Das ist leider die Krux. Solange das Ereignis (Unfall etc.) nicht eintritt, ist es ein rein theoretisches Problem, weil sich der Ausgang nicht unterscheidet. Wir werden damit tagtäglich im Auto mit einem Sicherheitsgurt konfrontiert, dass wir Maßnahmen gegen theoretische Sicherheitsprobleme ergreifen, die keinen messbaren Unterschied machen, solange das Ereignis nicht eintritt. Bei Unfällen kann man auf Statistiken zurückgreifen, aber bei Spectre wird es schwierig werden rückwirkend festzustellen, welcher Rechner durch Spectre kompromittiert wurde. Das ist generell bei solchen Exploits ein Problem.

Dieses Paper hier beschreibt das Problem sehr gut (speziell der Abschnitt "Claims of improvement rather than necessity" auf Seite 4): https://www.microsoft.com/en-us/research/wp-content/uploads/2015/09/unfalsifiabilityOfSecurityClaims.pdf

Allein für die Mukke (http://abload.de/image.php?img=043587sr3.jpg) habe ich 3 betroffene Systeme, wobei da nur ein Desktop mit 2600k online ist. Patche ich das alles, hab ich weniger Leistung(da hängen quasi alle Tools am CPU!) und wohlmögliche instabile Systeme, die mir während 'ner Session um die Ohren fliegen. Das steht hier in keinem rationalen Verhältnis - sorry.

Wenn die Systeme keinen Code dynamisch nachladen und Offline betrieben werden, gibt es natürlich keinen direkten Grund die zu patchen.

[BlackBirdSR]

Lösen wird man das wohl nur können, in dem man die Prozessorarchitektur grundsätzlich überdenkt. Möglicherweise muss man dazu sogar x86 anpassen.

Das ist ja kein Problem, welches nur x64 betrifft.

[Achill]

Nur zur Info, da man oft von fehlendem Support lesen muss:
----------------------------------------------------------------------------------------
vielen Dank für Ihre Anfrage.

Es wird ein neues BIOS Update geben für Ihr Mainboard.
Bis das BIOS bereitgestellt werden kann, wird es ca. 3 bis 4 Wochen dauern.
Für die Intel 8/9 und X99 Chipsätze wird es demnächst neue Mikrocode Version geben, welche dann in neue BIOS Files eingebunden werden.

Die passende BIOS Datei können sie dann auf der MSI Seite runter laden.
Rufen Sie dazu die Produkt Seite zu Ihrem Mainboard auf.

Eine Anleitung zum BIOS Update finden Sie hier:

Anschließend kopieren Sie das BIOS auf einen USB Stick, dieser muss FAT32 Formatiert sein.
Bitte die Bios Datei muss im Hauptverzeichnis liegen und darf nicht in einem Ordner abgelegt werden.
Dann bitte das BIOS aufrufen und dort Bios Update auswählen um das neuste BIOS aufzuspielen.
Der USB Stick sollte direkt an einem USB 2.0 Port hinten am Mainboard angeschlossen werden, nicht an einem Front Panel.
(Bei älteren Mainboard gibt es die Auswahl BIOS mit ME Update)

Als Hinweis, BIOS mit ME update gibt es nur bei Intel Mainboards.

Mit freundlichen Grüßen
Ihr MSI Tech. Support Team

------------------------------------------------------------------------------------
Das hier verbaute Mainboard ist ein Z87M Gaming mit einer Xeon E3 1230 V3 also ein Haswell-Ws CPU..........Ich finde es super von MSi :up:auch Boards zu bedienen die 4 Jahre auf dem Buckel haben.


Sieht bei mir nicht anders aus für mein X99-E WS ... immerhin soll ein Bios kommen auch wenn es auf der Update-Liste nicht erscheint.


Sehr geehrter Herr XYZ,

vielen Dank für Ihre Anfrage an den technischen Support.

Betreffend der Sicherheitslücke arbeiten unsere Software-Experten derzeit mit Hochdruck an BIOS Versionen, die den benötigten Microcode enthalten um die als "Meltdown" bekannte Sicherheitslücke zu schließen.
Ein exaktes Releasedate kann ich Ihnen derzeit noch nicht nennen, jedoch gehe ich davon aus, dass eine entsprechende Version in naher Zukunft bereit steht.
Die für Ihr Board notwendige Version ist intern bereits angekündigt und wird noch im Januar bereit stehen.

Daher möchte ich Ihnen gern empfehlen, sich in regelmäßigen Abständen auf unserer Webseite zu Informieren, ob zu Ihrem Board eine neue BIOS Version verfügbar ist.

Darüber hinaus möchte ich Ihnen empfehlen, verfügbare Sicherheitspatches für Ihr Betriebssystem zu installieren.

--> Don't understand german? Please let me know, I will answer in english.

Sind Ihrerseits noch Fragen offen, wenden Sie sich gerne wieder an uns!
Weitere technische Unterstützung finden Sie auch unter https://www.asus.com/de/support/
Sie erhalten in den nächsten Tagen per E-Mail einen Link zu unserer Zufriedenheitsumfrage.
Ich würde mich sehr freuen, wenn Sie an der Umfrage teilnehmen und meinen Service bewerten



Mit freundlichen Grüßen / Best regards
XYZ



Wenn es bis Ende Januar noch nicht da ist muss ich mal schauen was ich mache. Evtl. werde ich wohl an meinen Händler wenden mit der Bitte um Beseitung des Mangels ...

[Thunder99]

Nur zur Info, da man oft von fehlendem Support lesen muss:
----------------------------------------------------------------------------------------
vielen Dank für Ihre Anfrage.

Es wird ein neues BIOS Update geben für Ihr Mainboard.
Bis das BIOS bereitgestellt werden kann, wird es ca. 3 bis 4 Wochen dauern.
Für die Intel 8/9 und X99 Chipsätze wird es demnächst neue Mikrocode Version geben, welche dann in neue BIOS Files eingebunden werden.

Die passende BIOS Datei können sie dann auf der MSI Seite runter laden.
Rufen Sie dazu die Produkt Seite zu Ihrem Mainboard auf.

Eine Anleitung zum BIOS Update finden Sie hier:

Anschließend kopieren Sie das BIOS auf einen USB Stick, dieser muss FAT32 Formatiert sein.
Bitte die Bios Datei muss im Hauptverzeichnis liegen und darf nicht in einem Ordner abgelegt werden.
Dann bitte das BIOS aufrufen und dort Bios Update auswählen um das neuste BIOS aufzuspielen.
Der USB Stick sollte direkt an einem USB 2.0 Port hinten am Mainboard angeschlossen werden, nicht an einem Front Panel.
(Bei älteren Mainboard gibt es die Auswahl BIOS mit ME Update)

Als Hinweis, BIOS mit ME update gibt es nur bei Intel Mainboards.

Mit freundlichen Grüßen
Ihr MSI Tech. Support Team

------------------------------------------------------------------------------------
Das hier verbaute Mainboard ist ein Z87M Gaming mit einer Xeon E3 1230 V3 also ein Haswell-Ws CPU..........Ich finde es super von MSi :up:auch Boards zu bedienen die 4 Jahre auf dem Buckel haben.
Trifft nicht auf Gigabyte zu... :(
https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html

[Rache Klos]

BIOS Updates sind ja nicht zwingend nötig, Windows seit Version 7 kann Microcode in den Prozessor pumpen, bei Linux kann man es auch nötigen falls selbst ablegen. Also keine Panik, selbst wenn der Boardhersteller nicht reagiert, geht davon auch die Welt nicht unter.

[keats]

Mal abgesehen davon, dass mein Haswell scheinbar schon ein Update hat, ist mein letzter Stand:

Ich habe folgenden Haswell-Microcode in einem BIOS für einen Shuttle DS81 Barebone aktualisiert und auf einem Lenovo Laptop mit dem VMware Treiber geladen:

+-----------------------------------------------------------+
|No| CPUID | Platform | Version | Date | Size Hex |
+--+----------+----------+----------+------------+----------+
|01| 00040651 | 72 | 00000021 | 20-11-2017 | 00005800 |
+-----------------------------------------------------------+

(Der Microcode stammt aus Intels Download (https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873) vom 08.01.18.)

Sofern es kein Auslesefehler ist, wurden danach in beiden Fällen auf Windows 10 Pro x64 die Patches aktiviert. Warum das nun ausgerechnet bei Haswell schon im November geschehen sein soll und für neuere CPUs erst am 04-01-18, ist mir nicht ganz klar. Habe es nur getestet, weil ich die Behauptung auf Heise gelesen hatte.

PS: Auf noch einem Laptop mit Windows 8.1 x64 hatte ich danach unspezifische Probleme. Systemsteuerung öffnete nicht, Geräte-Manager öffnete nicht... Rückgängig gemacht und Probleme waren weg.

[-=Popeye=-]

Trifft nicht auf Gigabyte zu... :(
https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html


Die Liste scheint noch nicht vollständig zu sein, da in der Pressemitteilung auch X99 also Haswell-E erwähnt wird.

The newly released BIOS updates from GIGABYTE integrate the latest Intel advised CPU Microcode versions to mitigate issues potentially caused by the security vulnerability. Customers who have purchased a GIGABYTE board are strongly recommended to visit the GIGABYTE official website immediately for the latest BIOS updates. Please refer to the following micro link for the list of available BIOS updates by models (currently offers updates for models that support 6th/7th/8th generation Intel® Core™ processors and X99/X299 platform)

Quelle (http://www.gigabyte.eu/Press/News/1586)

[vanquish]

Ich habe folgenden Haswell-Microcode in einem BIOS für einen Shuttle DS81 Barebone aktualisiert und auf einem Lenovo Laptop mit dem VMware Treiber geladen:

+-----------------------------------------------------------+
|No| CPUID | Platform | Version | Date | Size Hex |
+--+----------+----------+----------+------------+----------+
|01| 00040651 | 72 | 00000021 | 20-11-2017 | 00005800 |
+-----------------------------------------------------------+

(Der Microcode stammt aus Intels Download (https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873) vom 08.01.18.)

Sofern es kein Auslesefehler ist, wurden danach in beiden Fällen auf Windows 10 Pro x64 die Patches aktiviert. Warum das nun ausgerechnet bei Haswell schon im November geschehen sein soll und für neuere CPUs erst am 04-01-18, ist mir nicht ganz klar. Habe es nur getestet, weil ich die Behauptung auf Heise gelesen hatte.

PS: Auf noch einem Laptop mit Windows 8.1 x64 hatte ich danach unspezifische Probleme. Systemsteuerung öffnete nicht, Geräte-Manager öffnete nicht... Rückgängig gemacht und Probleme waren weg.

Ist mir auch aufgefallen. Ich habe mir für drei Boards den Microcode selbst ins Bios "gepatcht" und dabei ist mir das Datum für den Haswell Microcode ins Auge gestochen. Aber da Intel das alles seit Mitte 2017 wusste wundert mich das ganze nicht wirklich.

Seltsames verhalten habe nur auf meiner Workstation mit Archlinux ohne Spectre-Patch aber mit Microcode-Update beobachten können (KDE Crashes). Ich vermute, dass es daran liegt, dass es für Archlinux noch keine Spectre-Patches gibt und/oder die Software insgesamt in jedem Bereich erst angepasst werden muss.

Microsoft hat hier wohl einen Vorsprung ggü. anderen, da sie wohl eingebunden waren. Die Linux-Veranwortlichen waren Intel wohl nicht vertrauenswürdig genug. :o

Auf der Zockmaschine mit Windows ist mir bisher nichts aufgefallen und am Server auch nicht (läuft allerdings auch mit Archlinux ohne Spectre-Patch).

[Ganon]

Seltsames verhalten habe nur auf meiner Workstation mit Archlinux ohne Spectre-Patch aber mit Microcode-Update beobachten können (KDE Crashes). Ich vermute, dass es daran liegt, dass es für Archlinux noch keine Spectre-Patches gibt und/oder die Software insgesamt in jedem Bereich erst angepasst werden muss.

Eigentlich (weiß ja keiner was Intel nun genau geändert hat) dürfte das Microcode Update unter ArchLinux gar keine Auswirkungen haben. Die Funktionen die Intel hinzugefügt hat werden hier gar nicht benutzt und werden vermutlich "per default" auch nie benutzt werden. Ist die Frage ob sie anderweitiges Standardverhalten geändert haben.

Nach dem bisherigen Stand sieht es so aus, als wenn im nächsten Kernel-Release (4.14.14) erst mal Retpoline zum Einsatz kommt, welches alles kleiner Skylake behandelt, vollkommen egal ob Microcode Update oder nicht. Dies wird in den nächsten Schritten weiter verbessert, damit man auch Skylake damit abdeckt.

Die Patches die den Intel Microcode brauchen (IBRS) schwirren noch umher und sind noch nicht Bestandteil des Kernels. Diese werden aber vermutlich für den Anwender "opt-in" bleiben.

tldr: Man hat also aktuell 2 Lösungen für ein Problem. Windows hat aktuell die Variante drin, die Microcode Updates braucht, Linux bekommt im nächsten Schritt die Variante die kein Microcode braucht und bekommt in Zukunft beide Varianten.

[vanquish]

Ja, jetzt wo Du es sagst habe ich noch einmal genauer nachgedacht was ich gemacht habe. :D ... Nach dem Bios-Update habe ich das System ohne auszuschalten direkt gebootet. Da kamen auch direkt zwei KDE-Crashes und der Specte-/Meltdown-Checker schrieb mir bei Spectre 2 SPEC_CTRL ein UNKNOWN hin. Nach einem "On/Off" erkannte der Checker den gepatchten Microcode. ...

Das mit der "Zukunft ohne Microcode" gefällt mir und war mir bisher nicht bekannt. Hat auch den Charme, dass man sich unter Linux keinerlei Gedanken darüber machen muss ob nun ein Microcode-Update kommt oder nicht.

[Birdman]

@Ganon
Linux/Retpoline nützt auch nur für CPU's älter als Skylake und auch da nicht zu 100%. Allenfalls kommt man damit auf einen ähnlichen Stand wie bei AMD/Ryzen. ("near zero risk")
IBRS und IBPB Support (für welchen man die Microcodes braucht) machen für einen noch besseren Schutz auch bei älteren Intel CPUs Sinn.
Ich sehe das auch hier ähnlich zu AMD/Ryzen, wo es ja auch Microcodes gibt um via IBRS/IBPB die Spectre_v2 Mitigation zu verbessern.

[Ganon]

Linux/Retpoline nützt auch nur für CPU's älter als Skylake und auch da nicht zu 100%.

Es gibt bereits Patches die das beheben. (http://lkml.iu.edu/hypermail/linux/kernel/1801.1/05556.html) Klar, nicht 100%, aber besser als gar nichts. edit: Und mein Text oben war auch keine Meinung sondern spiegelt das wieder, was vermutlich im Linux Bereich passieren wird. D.h. IBRS wird wohl optional bleiben, sofern sich die Meinungen nicht noch ändern.

[Birdman]

Ah, gut zu wissen, dass hier die Retpoline Patches erweitert werden (können) um auch für die neuen Intel CPU's zu wirken - das war mir neu.

Ja, bei IBRS und IBPB gehe ich auch davon aus dass diese optional bleiben werden. Der Performanceverlust gerade bei älteren CPUs scheint ja so gewaltig zu sein, dass diese damit quasi unbrauchbar würden.

[eratte]

Interessanter Vermerk bei CB zu der ASUS Liste:

Die öffentlichte Liste soll hingegen bis „allerspätestens Ende Januar“ abgearbeitet worden sein.

Da sind also noch 2 Wochen Luft drin, für den Rest heißt das noch länger warten

Sicherheitslücke Spectre: BIOS-Updates von ASRock, Asus, MSI und Gigabyte (Computerbase) (https://www.computerbase.de/2018-01/spectre-bios-updates-asrock-asus-msi-gigabyte/)

[Pirx]

einfaches Meltdown/Spectre-Tool von Gibson Research https://www.grc.com/inspectre.htm

[vanquish]

Ah, gut zu wissen, dass hier die Retpoline Patches erweitert werden (können) um auch für die neuen Intel CPU's zu wirken - das war mir neu.

Ja, bei IBRS und IBPB gehe ich auch davon aus dass diese optional bleiben werden. Der Performanceverlust gerade bei älteren CPUs scheint ja so gewaltig zu sein, dass diese damit quasi unbrauchbar würden.

Ich dachte eigentlich, dass der grösste Performance-Hit durch Meltdown und dem dazugehörenden Patch verursacht wird. Vor allem in Bezug auf ältere Systeme ohne PCID. Zu Spectre v1 habe ich gelesen, dass es kaum Auswirkungen hat. Spectre v2 hat wohl vor allem Auswirkungen auf virtualisierte Umgebungen, da hier eine Lücke bei der Trennung zwischen Gast und Host genutzt werden kann.

[Complicated]

Allenfalls kommt man damit auf einen ähnlichen Stand wie bei AMD/Ryzen. ("near zero risk")
Ein wichtiger Grund warum bei AMD "near zero risk" herrscht ist allerdings das verwenden der kompletten Speicheradresse in der branch prediction. Das "flattening" (verkürzen) der Adressen bei Intel CPUs kann IMHO nicht gepatched werden. Oder ist da etwas anderes bekannt?

Solange das nicht gepatched werden kann durch ein Microcode Update, wird Intel immer eine deutlich größere Angriffsfläche bieten für Spectre V2, sobald die branch prediction aktiv ist.

[konkretor]

Hat wer eine alte Möhre wie nen P2 oder älter und kann mit Linux den Patch einspielen?

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

Das geht runter bis zum Pentium

[Ganon]

Hat wer eine alte Möhre wie nen P2 oder älter und kann mit Linux den Patch einspielen?
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
Das geht runter bis zum Pentium

Wie schon mal gesagt, das ist der allgemeine Microcode Download für Intel Prozessoren und kein Download explizit für Spectre-Fixes.

[maguumo]

sobald die branch prediction aktiv ist.
Genau in die Kerbe schlagen doch IBRS, STIBP und IBPB soweit ich das verstanden habe.

[Complicated]

Hardwarelux hat eine Liste spezifisch für Meltdown/Spectre Microcodes. Allerdings alles für Linux-Distributionen:
https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/45319-intel-kaempft-mit-schwerer-sicherheitsluecke-im-prozessor-design.html?start=14

[Birdman]

Hardwarelux hat eine Liste spezifisch für Meltdoan/Spectre Microcodes. Allerdings alles für Linux-Distributionen:
https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/45319-intel-kaempft-mit-schwerer-sicherheitsluecke-im-prozessor-design.html?start=14
Denke ich nicht, die haben offensichtlich auch nur das aktuellste Microcode File genommen und alle darin unterstützen CPUs abgedruckt.
Für welche CPUs aber der Spectre_v2 Patch drin ist, wird nicht erwähnt.
Dass dem so sein muss, zeigt schon dass die abgedruckte Liste Itanium CPUs enthält....welche ja keinerlei Updates brauchen, da von Spectre/Meltdown nicht betroffen.

[Ganon]

Die Liste ist auch quatsch. Wie schon gesagt, das sind einfach nur ALLE Microcodes von Intel. Ob da ein Update erfolgt ist oder nicht, ist egal, sie landen alle in einem Archiv.

[Complicated]

Ich habe bisher noch keinen der Links angeklickt wo keine Microcode Updates für Linux Meltdown/Spectre vorhanden waren - habt ihr welche gefunden?
Das Datum war bei allen bisher auch aus 2018
Laut Hardwarelux:
Hier nennt Intel zahlreiche Modelle, deren Microcode bereits ein Update erhalten kann.
Es scheint also eine Liste zu sein von CPUs, welche ein update erhalten haben in 2018 - daher sind auch Itanium CPUs dabei. Wofür dieses Update ist, wird dadurch natürlich nicht klar. Vor allem wenn man die zurück gezogenen Updates in Betracht zieht.

[Ganon]

Nochmal zum dritten oder vierten Mal: Das ist ein Sammelpaket. Nur weil die Datenbank-Abfrage auf Core 2 Duo das Paket mit aktuellem Datum zeigt, heißt das nicht, dass der Microcode für den Core 2 Duo aktualisiert wurde. Und nein, ich denke mir das nicht aus!


Modellname: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz



[ 0.000000] microcode: microcode updated early to revision 0x95, date = 2010-10-02



intel-ucode 20180108-1

[Complicated]

Und inwiefern widerspricht das nun dem was ich geschrieben habe?

Es scheint also eine Liste zu sein von CPUs, welche ein update erhalten haben in 2018 - daher sind auch Itanium CPUs dabei. Wofür dieses Update ist, wird dadurch natürlich nicht klar. Vor allem wenn man die zurück gezogenen Updates in Betracht zieht.

[Ganon]

Dass alle Microcodes 2018 aktualisiert wurden ist trotzdem falsch und dass das Paket für Spectre Fixes ist ist auch falsch. Es ist ein Sammelpaket für alle Microcodes die Intel so hat... vollkommen unabhängig davon wie alt oder was sie fixen. Das Paket gibt es schon bald 10 Jahre und es hat seit dem seine Bedeutung nicht geändert.

[Complicated]

Vielleicht solltest du es ein drittes mal lesen - ich zitiere es nicht nochmal.
Dass alle Microcodes 2018 aktualisiert wurden ist trotzdem falsch und dass das Paket für Spectre Fixes ist ist auch falsch.Beides habe ich nicht geschrieben.

[Ganon]

Ich habe bisher noch keinen der Links angeklickt wo keine Microcode Updates für Linux Meltdown/Spectre vorhanden waren - habt ihr welche gefunden?
Das Datum war bei allen bisher auch aus 2018
Laut Hardwarelux:

Es scheint also eine Liste zu sein von CPUs, welche ein update erhalten haben in 2018 - daher sind auch Itanium CPUs dabei. Wofür dieses Update ist, wird dadurch natürlich nicht klar. Vor allem wenn man die zurück gezogenen Updates in Betracht zieht.

5. mal: Es wird immer auf das gleiche Paket verlinkt und es enthält alle Microcodes. Das Paket sagt nicht, dass es für Spectre ist (Meltdown sowieso nicht), noch dass alle der aufgelisteten CPUs ein Update bekommen hat.

Sorry, aber ich weiß echt nicht mehr was ich sonst noch dazu sagen soll, außer dass die Deutung von Hardwareluxx falsch ist und die Liste unnötig und redundant.

[Monsta]

Ich hatte bei einem Haswellsystem das Microcodeupdate von 2018 geladen.
Nach dem auslesen unter Linux war der geladene Haswellpatch von Ende 2017.
System war auch noch Spectre v1 & v2 anfällig.
Sind also nur ein paar Cpus gefixed worden.

[Ganon]

Ich hatte bei einem Haswellsystem das Microcodeupdate von 2018 geladen.
Nach dem auslesen unter Linux war der geladene Haswellpatch von Ende 2017.
System war auch noch Spectre v1 & v2 anfällig.
Sind also nur ein paar Cpus gefixed worden.

Ja, siehe meinen Kommentar hier: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11605905&postcount=1470

tl;dr: Das mainline Linux hat noch gar keinen Schutz gegen Spectre. Das Microcode Update alleine "fixt" gar nichts.

[vanquish]

Man kann es sich aber auch zusammen reimen.

Beispielsweise war mein Haswall bis vor kurzem auf Microcode Version 22, 01/2017. Nach bekannt werden der Sicherheitslücken kam direkt das Microcode Update via intel-ucode auf mein System (Version 23, 11/2017). Der Spectre Checker zeigte vor dem Update "Vulnerable" an. Danach auch brav, dass mein System gepatcht ist. D. h. das Microcode Paket von 2018 beinhaltet den Spectre Patch für die Haswell Generation. Ich habe unter Linux sogar die Gegenprobe gemacht und ein Rollback auf die Zeit vor dem Patch gemacht und den Spectre-Checker zeigte auch an, dass das System den Bios-Patch für Spectre hat.

Allerdings bin ich mir bei den ganzen Tools nicht sicher ob diese alles abdecken und/oder korrekt arbeiten. Insbesondere unter Windows. Kein Tool trifft eine Unterscheidung zwischen Spectre v1 und v2. Soweit ich weiss ist v2 unter Windows noch nicht gefixt oder?

[Monsta]

Dieses Tool unterscheidet zwischen den drei Varianten .

https://github.com/speed47/spectre-meltdown-checker

Ich habe lediglich Meltdown mit einem Kernelpatch zubekommen.
Das Microcodeupdate hatte zu Spectre nichts gebracht.

Kannst das ja mal testen.

[vanquish]

Spectre-Microcode Patch wurde erkannt. Da hier auf dem Arch Linux weder Spectre v1 noch v2 gepatcht sind, gibt es auch keinen Schutz hier auf diesem System.

[Monsta]

Dankeschön.

Ich war der Annahme das für Spectre V1 und V2 ein Biospatch reicht.

Und bei Anpassungen des Compilers man sogar auf das Microcode update verzichten kann.

[vanquish]

Dankeschön.

Ich war der Annahme das für Spectre V1 und V2 ein Biospatch reicht.

Und bei Anpassungen des Compilers man sogar auf das Microcode update verzichten kann.

Ganon hat den Umstand, dass man auf das Microcode Update verzichten kann ein paar Seiten vorher schon erwähnt. Und in dem Spectre Skript steht es auch drinnen. :D Stichwort: "Kernel with Retpoline". Wie das dann genau aussieht und welche Vor- oder Nachteile die jeweilige Lösung hat wird sich dann zeigen wenn die Patches da sind.

[PrivateCeralion]

Dankeschön.

Ich war der Annahme das für Spectre V1 und V2 ein Biospatch reicht.

Und bei Anpassungen des Compilers man sogar auf das Microcode update verzichten kann.

Da Hacker so nett sind und den Spectre sicheren Compiler benutzen.

[gravitationsfeld]

Das ergibt keinen Sinn. Der Hacker muss keinen Compiler benutzen. Man kompiliert das Program mit einer speziellen Compiler-Flag, die gegen Spectre schuetzt.

[PrivateCeralion]

Das ergibt keinen Sinn. Der Hacker muss keinen Compiler benutzen. Man kompiliert das Program mit einer speziellen Compiler-Flag, die gegen Spectre schuetzt.

Der Hacker schreibt ein Programm, welches Spectre ausnutzt. Selbstverständlich compilt er es mit einem alten compiler. Dann lässt er es auf einer virtuellen Maschine in der Cloud laufen. Somit kann er Daten klauen.