Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsMeltdown & Spectre: Details und Benchmarks zu den Sicherheitslücken in CPUs
spectre 2 kommt also nur zum tragen, wenn der user "local user access" hat, also, sprich: er sitzt vor dem betreffenden rechner. werde ich vernachlässigen können, denke ich mal.
Ich war mit Intel seit meinen Anfängen in den x86-Zeiten (286 war der erste) sehr zufrieden.
Da leider Langlebig- und Ehrlichkeit in der heutigen Gesellschaft wenig wert ist, hat sich auch Intel verändert, wie viele andere.
Der Umgang mit dem Fehler wird zeigen, ob es nochmals Intel wird, bei der Vorstellung zu Ryzen und dem Erscheinen hat man gesehen, wie AMD seine Hausübungen für eine gute Alternative gemacht hat. Das heißt, das nächste System könnte durchaus ein Threadripper werden - insgesamt scheint AMD am Boden geblieben und etwa bei den Sockeln dem Kunden weniger Schwierigkeiten mit nötigen Wechseln zu gängeln.
Und gerade bei den älteren Systemen wird das Argument dann immer wieder kommen, sich aufgrund der Sicherheit meiner Daten, ein neues System anzuschaffen.
So kann man Hardware mit 5 Jahren Alter einfach hinten abrasieren um neue Hardware abzusetzen. Und dann zu Preisen, die frei bestimmt werden können.
So ist das mit der Wirtschaft / Markt nunmal geworden - wer kann sich dem entziehen ? Das ist die eigentliche Unverschämtheit hinter solchen Problemen die solche evtl sogar geplanten Sicherheitslücken stecken.
Ich glaube nicht das diese Lücke geplant war. Eher traue ich Intel zu, dass damals diese "Sicherheitslücke" für den Performance-Boost in Kauf genommen wurde, da es keinen bekannten Exploit gab diese auszunutzen.
Aber freiwillig würde sich Intel diesen Shitstorm mit Sicherheit nicht geben, da es sie im wichtigsten Markt Kunden kosten wird, wie viele lässt sich nicht sagen, aber einige werden im Server-Markt bei der nächsten Anschaffung mit Sicherheit die Konkurrenz in Betracht ziehen. Sowas würde Intel niemals freiwillig tun.
Na, die Frage wäre ja, wie sehr Intel aus dieser Geschichte profitiert.
Denn, ganz ehrlich, nicht jeder kauft jetzt AMD Hardware.
Und Intel wird ganz sicherlich ein Schublädchen öffnen, und eine sichere V 2.0 Hardware entwickeln.
Bis hierhin ist Intel mit deren Klecker-Verbesserungs-Variante auch bestens gefahren. Jetzt läuft das gerade ein bisschen anders.
Aber unterm Strich wird das für Intel trotzdem eine Win-Win-Situation.
Nicht jeder, aber genügend werden das tun. Und diejenigen welche halt immer weiter blind Intel kaufen (obwohl sie es für ihre Anwendungszwecke nichtmal annähernd bräuchten) sind dann halt auch selbst Schuld.
Aufjedenfall wird das keine Win-Win Situation für Intel. Der Image-Schaden ist enorm und bis sichere Hardware entwickelt ist, vergehen vermutlich 1-2 Jahre, also so schnell wird man das nicht ausbügeln können. Und noch ist nicht überall alles gefixt und die wahren Leistungseinbußen bekannt.
Leuchtet ein .... was mich dabei verwundert: mit welcher Nicht-Tranzparenz Intel der Sache begegnet.
Wir tun also gut, unsere nicht gefixten Rechner weiterhin zu benutzen, und in der nächstgelegenen Kirche eine Kerze anzuzünden um keinem
Angriff ausgesetzt zu werden.
ich denke das man bereits versagt hat was den Umgang mit dem Fehler betrifft, dazu gehört auch das man "scheinbar" so wie ich z.b. mit seiner guten alten "Sandy" in die Röhre schaut.
Ich HATTE ja den 8700K schon hier liegen, auch wenn ich mit Intel bisher sehr zufrieden war, so kann ich das scheinheilige getue und die Arroganz nicht unterstützen.
Auch AMD ist und wird nie frei von jeglichem Fehler sein, dennoch investiere ich mein Geld lieber erst einmal in Produkte bei denen ich "weniger" Sauer aufstoßen muss, bzw. warte erst mal die nächsten Wochen ab.
Im übrigen hat mein HP 450 G3 bereits seit gestern das Bios Update mit dem 6200U das finde ich vorbildlich, wenn man bedenkt das es hier nicht der neuste ist.
mein Lenovo Yoga 500 (gleiche CPU) ist noch nicht einmal in der " angedachten Update Liste " auch hier kann man dann Spreu von Weizen ganz gut trennen.
bedeutet wohl eher du brauchst es aber bekommst es nicht per bios-Update. Spectre-Lücke lässt sich nur per Microcode-Update schließen. Wird einem auch in PowerShell so angezeigt, wenn man den test fährt.
Diese Script ist kein Test auf die Lücke, sondern fragt lediglich Windows-Informationen ab.
inge70 schrieb:
Ein Microcode-Update mittels den VMWare-Tool brachte nix (wie im 14. Update zur News auch schon beschrieben wurde), da Windows den Microcode schon VORHER prüfte und somit keine Änderung mehr zu lies.
Da habe ich Zweifel dran, denn das MC-Update per Windows muss ja auch bei "ungepatchten" Windows-Versionen funktionieren. Warum sollte sich an dem Verhalten etwas ändern?
Die ArchWiki ist evtl. mal einen Blick wert im Bezug auf Microcode. https://wiki.archlinux.org/index.php/microcode
In den Fall wird der µC in den CPU geschrieben bevor Windows startet und somit sollte es funktionieren.
Das wird, und ich sage das ausdruecklich, LEIDER, praktisch keine Auswirkung auf die Beschaffung haben. Am meisten wird Intel hier den Absatz steigern koennen. Ich sage LEIDER, weil es offensichtlich ist das Intel hier bewusst gearbeitet hat. Ob das nun eher performancegruende hatte oder andere lass ich mal offen. Aber AMD wird davon ungefaehr soviel profitieren koennen wie Linux vom Vista release.... einfach weil ITler nunmal sind wie sie sind.
Fuer den Bug von Intel koennen sie ja nichts, aber wenn Dell sagt, nehmen sie die Intel Maschine, dann wird das auch so gemacht. Und Dell und HP etc sind immernoch fest in Intels Hand.
Ich bin seit 20 Jahren in der Branche, da redest du gegen eine Wand.
Die ArchWiki ist evtl. mal einen Blick wert im Bezug auf Microcode. https://wiki.archlinux.org/index.php/microcode
In den Fall wird der µC in den CPU geschrieben bevor Windows startet und somit sollte es funktionieren.
Falsch, der Microcode unter Linux/Arch wird beim booten des Linux Kernels in die CPU geschrieben. Das nützt dir mit Windows rein gar nichts. Deine Annahme scheint wohl zu sein das Grub bereits den Microcode lädt, aber das ist nicht der Fall.
Das kann ich dir sogar beweisen, anhand der Kernel log:
Die ArchWiki ist evtl. mal einen Blick wert im Bezug auf Microcode. https://wiki.archlinux.org/index.php/microcode
In den Fall wird der µC in den CPU geschrieben bevor Windows startet und somit sollte es funktionieren.
Lädt Grub auch ne initrd wenn kein Linux als OS ausgewählt ist? Das steht im Link nicht so da und ich kann es mir auch nicht vorstellen, da das ja ne Ramdisk ist.
Da habe ich Zweifel dran, denn das MC-Update per Windows muss ja auch bei "ungepatchten" Windows-Versionen funktionieren. Warum sollte sich an dem Verhalten etwas ändern?
Wie dem auch sei, ich habe das VMWare-Tool auf 2 Geräten, einem Acer aspire Z5610 und einem Acer Aspire S3-391, unter Windows10 genutzt (da kann man ja nicht viel falsch machen, wenn man sich an die Anleitung hält). In beiden Fällen wurde mir durch die Install.bat zwar "erfolgreich" gemeldet aber im Ereignisprotokoll stand dann "das System benötigt diesen Treiber scheinbar nicht oder ist aktueller". Fragt sich also: was lief da schief? Der Intel-Microcode stammt vom 08.01.2018.
man vermutet, dass Windows die Microcode-Abfrage bereits früher durchführt und somit der VMWare-Treiber, der den aktuellen Microcode nachläd (immer beim Systemstart), nicht mehr zum tragen kommt. es passiert ja alles in der Windowsumgebung.
Ich hab es mehrmals versucht auf beiden Systemen, da dort kein Bios-Update zu erwarten ist seitens Acer, weil zu alt (1x Core2Quad und 1x Core i3 3217U).
Und wie sieht es bei AMD aus? Hüllen sich komplett in Schweigen.
Da gibt es nicht mal eine Liste, welche CPU betroffen bzw. nicht betroffen sind.
Microcode-Updates = Fehlanzeige.
Support geht anders!
Stimmt, worauf ich eigentlich hinaus wollte ist die Verwendung von mcu, wobei das wohl kein Bestandteil von Grub ist.
Eine Implementierung des Programms ist unter https://biosbits.org/ zu finden.
Dieses funktioniert auch bei Windows.
Bits lässt sich auch auf einen USB Stick installieren und dort starten. Nach dem µCode Update kann man dann weiter ins Windows booten.
Ich hab es mehrmals versucht auf beiden Systemen, da dort kein Bios-Update zu erwarten ist seitens Acer, weil zu alt (1x Core2Quad und 1x Core i3 3217U).
Für diese CPUs ist ja auch gar kein Microcode Update im letzten Update von Intel drin. Also ist "das System benötigt diesen Treiber scheinbar nicht oder ist aktueller" völlig normal.
