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

@Don
Wann korrigierst du die Liste mit gepatchten Intel CPUs? Der Artikel ist immer noch komplett falsch!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich finde es schon komisch, da hat Intel, ein Milliardenunternehmen mit wahnsinnig viel Intelligenz, seit Juli letzten Jahres Wissen über diese Lücke und dann bringen die nach 6 Monaten Microcodes heraus, die stellenweise die Rechner abschmieren lassen. Ist echt eine tolle Leistung.
 
Ein unkontrollierter Absturz ist da nicht so lustig.

Was meist du wie sich der Admin freut wenn sein im VORFELD verbautes Sicherheitskonzept aufgeht?
Es gibt in diesen Gefilden Konzepte auf HA Basis, da kannste die Putzfrau mit nem Einer Wasser durch RZ schicken und ganz geschickt mal stolpern lassen - und der Anwender merkt vom kompletten Systemausfall schlicht und ergreifend absolut gar nichts, außer dass vllt ein paar der Zutrittsberechtigten Personen etwas unruhig im Haus rumlaufen um zu Prüfen, was los ist...

Und was machst du wenn du lange Berechnungen durchführst und der Rechner schmiert andauernd ab? Oder durch die andauernden Abstürze wird das System zerschossen?

Der gesunde Menschenverstand (so denke ich zumindest) sagt mir in dem Fall erstmal - prüfe was der Grund ist, bevor du in wilde Panik verfällst...

Gibts hier irgendwo auch nur im Ansatz ne Beschreibung über das was A) Intel da verändert hat und B) unter welchen Konstellationen es zu Fehlern kommt/kommen soll?
Ich hab hier recht große Virtualisierungshosts, teile davon sind mit dem Microcode Update verartztet und das läuft 24/7 ohne schmerzen bisher.
Ich wüsste nicht, wozu ich da jetzt anfangen sollte Panik zu schieben - vor allem nicht, wo nichtmal bekannt ist, das der Prozessor ausführen muss um abzuschmieren.


VMware bspw. hat das Microcode Update mittlerweile zurück gezogen, wie ich gestern abend erst drüber gestolpert bin.
VMware Knowledge Base
Interessant dabei ist der Part:
"Intel has notified VMware of recent sightings that may affect some of the initial microcode patches that provide the speculative execution control mechanism for a number of Intel Haswell and Broadwell processors. The issue can occur when the speculative execution control is actually used within a virtual machine by a patched OS."

Heist soviel wie, wenn die Software das nutzt, was Intel da über den Microcode durchscheinen lässt, gibts ggf. Probleme. Das schränkt den Spaß zumindest schonmal ein... Unter welchen Bedingungen genau, weis ich im Moment nicht...
-> für die Jenigen, die hier meinen die Dinger schmieren nun unkontrolliert ab oder so...

Aber das ist wieder so ein Community-Ding. Absolut keinen Plan vom Background, aber das Fazit ist lange schon im Vorfeld gefällt :stupid:
 
Intel sagt, die Sicherheit geht vor Stabilität.
Also sicherer, als das der PC gar nicht mehr hochfährt geht es eigentlich nicht! :d
 
Doch, die ME muss nur noch selbständig die Platte(n) verschlüsseln, aber der CPU sagen, dass diese die Platten nicht entschlüsseln darf :d :fresse:

Zum Glück haben Schulen eh meist Rechner mit Sandy/Ivy CPUs und die werden (zumindest nach dem was ich bisher gesehen habe) eh nie gewartet :d (manche Grundschulen haben wirklich noch Pentium 3/4 Systeme)
(Einmal haben die aus versehen was falsch gemacht und Windows 7 konnte Updaten, waren nur über 230 Updates :d (und die Schulrechner für nen ganzen Tag unbenutzbar)
 
Zuletzt bearbeitet:
aaaah, die intel-sonne scheint wieder.
letzte woche urlaub gehabt, oder was war los?

aber es gibt ja HA konzepte mit FT und blabla, da machts gar nichts wenn gelegentlich ein paar hosts abschmieren.
vergessen hast du wohl, dass das alles irgendwie gar nicht so ganz umsonst zu haben ist. weder von der infrastruktur, redundanzen und natürlich lizenzen.

aber wehe eine cpu in der heimischen gaming-mühle verbraucht 30ct mehr strom im jahr....
 
Zuletzt bearbeitet:
Was wäre eigentlich, wenn die neuen Microcodes noch mehr Leistungseinbußen mit sich bringen würden, weil Intel zb bisher auf Kosten der Stabilität versucht hatte die Leistungseinbußen möglichst gering zu halten :confused:
 
Ich finde es schon komisch, da hat Intel, ein Milliardenunternehmen mit wahnsinnig viel Intelligenz, seit Juli letzten Jahres Wissen über diese Lücke und dann bringen die nach 6 Monaten Microcodes heraus, die stellenweise die Rechner abschmieren lassen. Ist echt eine tolle Leistung.

Ich finde das theoretisch gar nicht mehr komisch, da meine Geräte ja auch teilweise davon betroffen sind - das einzige, was ich noch ganz amüsant finde, ist eben, dass die mit Linux laufen und ich deshalb erst mal selbst nichts mit irgendwelchem manuellen Einspielen von Patches/Biosupdates etc. zu tun habe. :banana:

Aber so richtig freue ich mich jetzt nicht direkt, weil ich außer meinem Ryzen-Rechner(der auch im Vertrauen bei mir gelitten hat) meinen Laptops schon kaum mehr irgendwie traue - sie fühlen sich jetzt irgendwie beim Benutzen "verseucht" an, wie wenn man Schimmel auf seinem Käse im Kühlschrank findet. Es wäre deshalb mal sehr nett, wenn es mal endlich einen klaren Fix für all diese unendlichen Sicherheitslücken gäbe, die in der Management Engine, in der gesamten 64 Bit-Architektur und dem ganzen Kram seit vielen Jahren unbehoben schlummern - nur leider hört es einfach nicht auf, wie ein Fass ohne Boden...

Es ist schon für die ganze Computerbranche eine massive Katastrophe, aber man muss schon sagen, was Intel abliefert... da zieht es einem die Schuhe echt aus. Da fehlen mir jetzt auch die Worte.
 
Was meist du wie sich der Admin freut wenn sein im VORFELD verbautes Sicherheitskonzept aufgeht?
Es gibt in diesen Gefilden Konzepte auf HA Basis, da kannste die Putzfrau mit nem Einer Wasser durch RZ schicken und ganz geschickt mal stolpern lassen - und der Anwender merkt vom kompletten Systemausfall schlicht und ergreifend absolut gar nichts, außer dass vllt ein paar der Zutrittsberechtigten Personen etwas unruhig im Haus rumlaufen um zu Prüfen, was los ist...

Wenn Dir Deine Workstation beim Kopieren oder Bearbeiten von größeren Datenmengen so abschmiert, dass die Daten, die auf dem Storage System liegen, korrumpiert werden, dann hilft die die ganze syncrone Spiegelung nix. Der Mist wird dann nämlich auf beiden Seiten Deines HA-Pärchens gleichzeitig korrumpiert, syncron nämlich. Du kannst dann anfangen, dass Backup einzuspielen. Und ob Du auf dem Storage alle paar Minuten nen Snapshot hast, auf den Du zugreifen kannst, sei mal dahingestellt. Die Arbeit von ner halben oder ganzen Stunde ist da gleich mal im Eimer.

Dein HA-Gedöns hilft dir in dem Fall reichlich wenig. Wenn Dir die Puzfrau den Strom zieht, weil sie den Eimer umkippt ist ne ganz andere Sache. Da hast Du mit deinem syncronen HA-Pärchen erfolg. Aber eben nicht, wenn Dir Deine gespeicherten Daten kaputt gehen. Da hilft Dir nur Backup.

Cunhell
 
@oooverclocker Mein "komisch" war auch mehr als enttäuschend zu sehen.
Mir macht es den Eindruck, dass Intel noch gar nicht soweit war bzw. den Fehler bisher überhaupt nicht bearbeitet hat sowie sich die Updatepolitik bzw. die Updates verhalten/darstellen.
Vielleicht wollten sie ihn auch gar nicht beheben...?
 
Aber so richtig freue ich mich jetzt nicht direkt, weil ich außer meinem Ryzen-Rechner(der auch im Vertrauen bei mir gelitten hat) meinen Laptops schon kaum mehr irgendwie traue - sie fühlen sich jetzt irgendwie beim Benutzen "verseucht" an, wie wenn man Schimmel auf seinem Käse im Kühlschrank findet. Es wäre deshalb mal sehr nett, wenn es mal endlich einen klaren Fix für all diese unendlichen Sicherheitslücken gäbe, die in der Management Engine, in der gesamten 64 Bit-Architektur und dem ganzen Kram seit vielen Jahren unbehoben schlummern - nur leider hört es einfach nicht auf, wie ein Fass ohne Boden...

Es ist schon für die ganze Computerbranche eine massive Katastrophe, aber man muss schon sagen, was Intel abliefert... da zieht es einem die Schuhe echt aus. Da fehlen mir jetzt auch die Worte.

Ja, sehe ich auch so. Windows hat ähnliche Probleme. Wenn man Computerfachzeitschriften kauft - und das mache ich schon fast 35 Jahre - dann stehen da Überschriften wie, "Backuptools", "Windows wieder herstellen", "Wie sie sich schützen können", "Windows in Gefahr", "Windows spioniert sie aus", "Diese Tools schützen Ihr Windows" .... die Liste ist unendlich lang. Das nervt. Klar gibt es Alternativen, aber manchmal hat man keine Option, je nach Anwendung.
Das größte Problem liegt im Befehlssatz und die logische Ausführung in den Prozessoren (Leiterbahnen). Die sind klar definiert und machen keine Wahrscheinlichkeitsausführung. Der Prozessor macht nur stupide seinen Job, was ihm in den Register gesagt wird. Eigentlich ist der Prozessor Strohdumm. Intelligenter wird es dann mit dem Mikrocode (Bios, Kernel) und Programmierhochsprachen. Wenn unsauber programmiert wurde, dann gibt es den bekannten Absturz (Herunterfahren), Feezeschleife (Reset) oder bei neueren Prozessoren das Abfangen solcher Probleme mit entsprechender Fehlermeldung (Hardwarebasierter Taskmanager im Prozessor). Also ein Fass ohne Boden. Solange Schadsoftware die Prozessorfunktion an sich reißt, dann hat man keine Chance weil alle Programme ausgehebelt werden. Da hilft nur der Ausschaltknopf. Ausbauen der Festplatte, neue Festplatte rein, Bios neu aufspielen, Betriebssystem neu installieren.
Eigentlich hatte ich großes Vertrauen in den Chiphersteller und Betriebssysteme, dass wir als Enduser nicht verarscht werden und sicher sind. Falsch gedacht.
 
Es wäre deshalb mal sehr nett, wenn es mal endlich einen klaren Fix für all diese unendlichen Sicherheitslücken gäbe, die in der Management Engine, in der gesamten 64 Bit-Architektur und dem ganzen Kram seit vielen Jahren unbehoben schlummern - nur leider hört es einfach nicht auf, wie ein Fass ohne Boden...
In Intel-Prozessoren mit Support für x86-64 befindet sich offenbar eine gravierende Sicherheitslücke, die es Angreifern erlaubt, auf prozessfremde Speicherbereiche zuzugreifen. Da es sich dem Vernehmen nach um einen Hardware-Bug handeln soll, der nicht mit einem Microcode-Update gefixt werden kann, ist die Bedrohungssituation potenziell erheblich, schließlich stecken in der überwiegenden Mehrzahl der x86-64-Systeme Intel-Prozessoren. Der Bug ist unabhängig vom Betriebssystem – Windows, Linux und MacOS sind betroffen.
...
Da AMD von dem Bug nicht betroffen ist, obwohl x86-64 seinerzeit von AMD entwickelt worden war, lässt darauf schließen, dass der Fehler nicht im Befehlssatz an sich steckt, sondern in der speziellen Implementierung durch Intel.
Quelle: Massive Sicherheitslücke in Intel-CPUs (Update: AMD, ARM, Bugfixes) | Planet 3DNow!

Naja, was soll man dazu noch sagen?
 
Sicher ist, dass NICHTS sicher ist.
Wer weiß was noch für Bugs in unserer Hardware sind (egal von welchen Hersteller).
 
Was mich wundert: Sicherheitslücke? Eher Backdoor - die eben der Öffentlichkeit aufgefallen ist.
Meiner Meinung nach muss man hier kein Stress machen.
 
Nervt, habe selber noch einen älteren Sandy der mit 4,5 Ghz noch ganz gut mithält von der Leistung her. Und gerade ältere Prozessoren bzw Plattformen sollen ja nach den Updates von Instabilitäten geplagt sein. Ein Schelm wer böses denkt. War erstmal mein letzter Intel bis das Problem auch hardwareseitig gelöst wird.
 
Aber so richtig freue ich mich jetzt nicht direkt, weil ich außer meinem Ryzen-Rechner(der auch im Vertrauen bei mir gelitten hat) meinen Laptops schon kaum mehr irgendwie traue - sie fühlen sich jetzt irgendwie beim Benutzen "verseucht" an, wie wenn man Schimmel auf seinem Käse im Kühlschrank findet.

Ein Lösung, bis zum Erscheinen von Microcode Patchen, könnte sein:
Eine VM zum surfen auf diversen "Tittenseiten" etc. zu nutzen (Also als Sinnbild für Seiten allerlei Art, welchen man im Zweifel kein Vertrauen schenkt) Eben bis stabile Microcode Updates erscheinen und auch eingespielt werden können.

Denn (man möge mich korrigieren) so ich verstehe, ist Meltdown (Also u.a. das Ausbrechen einer VM aus dem Hypervisor) bereits mit dem OS Update gefixt:
Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]


Mit Spectre können sich Anwendungen dann dennoch gegenseitig in der VM in die Daten schauen. Aber das sollte kein Problem sein, wenn man auf der VM andere OS User und Passwörter nutzt und diese eben nur zum Surfen einsetzt, also dort keine sensiblen Daten liegen.
Man sollte sich dann auf der VM im Browser natürlich nicht bei Paypal oder gerenerell irgendwo mit User/PW einloggen.

Dazu kann man eine zeitlich begrenzte Window Eval nutzen oder z.B. dauerhaft ein Ubuntu Linux.
(Bei den meisten Linux Destris sollte eine erfolgreiche Installation schon seit einigen Jahren keine Hürde mehr darstellen).

Als Hypervisoren taugen VMware Player oder Oracle virtual Box (beide frei, für den Player muß man sich registrieren aber ohne Kosten).
Oder (das in Windows 10 Pro an Board befindliche) Hyper V (Das muß man in den Features dann noch aktivieren).
 
Zuletzt bearbeitet:
Scheint zumindest so, als würden die neuen Microcodes das Risiko einschränken.


und wieder zurück auf den Status Quo vor 19.1.2018, da die Microcodes halbgar scheinen..................:wall:
 
Zuletzt bearbeitet:
Hast du ein BIOS-Update vom Hersteller bekommen oder selbst implantiert?
Asrock hat mir geschrieben, dass die BIOS-Updates für das X99X Fatal1ty Killer in Arbeit sind...
 
Wenn Dir Deine Workstation beim Kopieren oder Bearbeiten von größeren Datenmengen so abschmiert, dass die Daten, die auf dem Storage System liegen, korrumpiert werden, dann hilft die die ganze syncrone Spiegelung nix. Der Mist wird dann nämlich auf beiden Seiten Deines HA-Pärchens gleichzeitig korrumpiert, syncron nämlich. Du kannst dann anfangen, dass Backup einzuspielen. Und ob Du auf dem Storage alle paar Minuten nen Snapshot hast, auf den Du zugreifen kannst, sei mal dahingestellt. Die Arbeit von ner halben oder ganzen Stunde ist da gleich mal im Eimer.

Dein HA-Gedöns hilft dir in dem Fall reichlich wenig. Wenn Dir die Puzfrau den Strom zieht, weil sie den Eimer umkippt ist ne ganz andere Sache. Da hast Du mit deinem syncronen HA-Pärchen erfolg. Aber eben nicht, wenn Dir Deine gespeicherten Daten kaputt gehen. Da hilft Dir nur Backup.

WENN das der Fall sein sollte, dann wäre schlicht mein Sicherheitskonzept für den Arsch...
Sorry, aber das ist kein Argument. Sicherheit ist nicht 0 oder 100. Sicherheit baut auf ein Prinzip vom Anfang einer Kette bis zum aller letzten Kettenglied. WENN es so kreuzgefährlich ist, diese Datenmengen zu kopieren und ein Absturz der Kiste korrupte Daten bedeutet, dann wäre ein sinnvoller Punkt im Konzept vllt der Einsatz einer VDI Lösung. Voll-Redundantes HA System, unterbrechungsfrei bei Hostausfall. Fertig die Kiste... Da gibts keinen SPoF (mehr) in der Kette, der dich behindert... Meine "Workstation" wäre dann nur noch ein dummer zero client. Oder ich nutze gleich Speichertechniken, die Änderungen rückstandslos tracken um diese im Zweifel zurückzuspielen. Nicht umsonst gibt es bspw. Transaction Logs in DB Systemen. Warum also nicht ein entsprechendes System nutzen anstatt stumpf auf ext4 oder NTFS drauf zu kopieren? Oder auch Checksummenbasierte Filessysteme, gepaart mit Redundanz, diese Fehler durch korrupte Daten zu erkennen und zu beseitigen.


Aber mal ehrlich, man sollte schon die Kirche im Dorf lassen... Es gibt wahrscheinlichere Ursachen für korrupte Daten. Bspw. der Stromausfall, ein Bluescreen, ein Treiberfehler und all der ganze Geraffel... Sich jetzt hier an einer Sache festzubeißen, weils gerade durch die Medien geht, kann man machen, ändert aber im gesamten nichts. Wer sich und seine Daten ernsthaft gegen derartiges Zeug schützt, hat nicht ne Single Workstation irgendwo rumstehen. Ungesichert... Läuft also gar nicht in das Problem, das ein Absturz der Client-Kiste die Serverdaten korrumpiert. Und wer das doch macht, der sollte sich dann halt nicht wundern, DASS sowas passieren kann ;)

Auf Intel-CPUs kostet aber auch Retpoline allerdings im Gegensatz zu AMD-Prozessoren merklich Leistung:
Benchmarking Retpoline Underflow Protection With Intel Skylake/Kabylake - Phoronix

Der i9 kopiert nur noch halb so viele Dateien pro Sekunde.

Wo siehst du dort bitte, dass da Zahlen im Gegensatz zu AMD stehen??? -> steht nichts vom im Link
Und wo siehst du dort, dass da nur noch halb so viele Daten kopiert! werden? -> steht auch nichts von im Link

Ein Lösung, bis zum Erscheinen von Microcode Patchen, könnte sein:
Eine VM zum surfen auf diversen "Tittenseiten" etc. zu nutzen (Also als Sinnbild für Seiten allerlei Art, welchen man im Zweifel kein Vertrauen schenkt) Eben bis stabile Microcode Updates erscheinen und auch eingespielt werden können.

Denn (man möge mich korrigieren) so ich verstehe, ist Meltdown (Also u.a. das Ausbrechen einer VM aus dem Hypervisor) bereits mit dem OS Update gefixt:
Speculation control settings for CVE-2017-5754 [rogue data cache load]


Wozu ne VM? Macht doch keinen Vorteil in dem Fall. Via Spectre kannst du mehr oder weniger beliebig im Userspace hantieren. Nicht also nur IN der VM, sondern potentiell im kompletten Userspace des Hosts... Und das innerhalb der VM ;) Genau das macht die Sache ja so spaßig... Meltdown ist dagegen ja ein laues Lüftchen. Kostet Leistung ja, aber den Fix auf dem Blech installiert und definitiv sicher. Weil die Daten nicht mehr vorhanden sind.
 
Wozu ne VM? Macht doch keinen Vorteil in dem Fall. Via Spectre kannst du mehr oder weniger beliebig im Userspace hantieren. Nicht also nur IN der VM, sondern potentiell im kompletten Userspace des Hosts... Und das innerhalb der VM ;) Genau das macht die Sache ja so spaßig... Meltdown ist dagegen ja ein laues Lüftchen. Kostet Leistung ja, aber den Fix auf dem Blech installiert und definitiv sicher. Weil die Daten nicht mehr vorhanden sind.

Es ist Wochenende und (je nach wie man will) spät (oder früh) am Abend , daher sorry, falls ich etwas nicht blicke. Aber Deine Antwort enhält einige Wiedersprüche. Vermutlich meintest Du mit "Und das innerhalb der VM" eher "von der VM hraus". Ja der Hypervisor ist auf dem Host auch nur ein Programm. Aber nach meinem Verständnis, auf Grund der Technik, dennoch vom Host isoliert. Ich verstehe, worauf hinaus willst. Aber die Antwort lasse ich so nicht gelten. Ich sehe den Userspace der VM von dem des Host isoliert, daher greift Spectre imo nicht vom Userspace der VM auf den Userspace des Host. Anderenfalls, bitte um valide Erklärung.
 
Zuletzt bearbeitet:
Es ist Wochenende und (je nach wie man will) spät (oder früh) am Abend , daher sorry, falls ich etwas nicht blicke. Aber Deine Antwort enhält einige Wiedersprüche. Vermutlich meintest Du mit "Und das innerhalb der VM" eher "von der VM hraus". Ja der Hypervisor ist auf dem Host auch nur ein Programm. Aber nach meinem Verständnis, auf Grund der Technik, dennoch vom Host isoliert. Ich verstehe, worauf hinaus willst. Aber die Antwort lasse ich so nicht gelten. Ich sehe den Userspace der VM von dem des Host isoliert, daher greift Spectre imo nicht vom Userspace der VM auf den Userspace des Host. Anderenfalls, bitte um valide Erklärung.
Durch den Bug ist es eben doch moglich, aus dem Gast auf den Host zuzugreifen.
Der Grund warum erstmal viele vServer Anbieter panisch auf Patches gewartet haben denn: Im Grunde alle VM Host nutzen die Virtualisierungstechnik der Prozessoren
 
Naja, letztlich sind das Probleme der großen Server-Betreiber. Uns Endkunden geht das Problem eigentlich nicht viel an, weil eine ganz andere Problematik dahintersteckt:

PCGH schrieb:
Trotzdem wurden mit den Spectre-Beispielattacken bis zu 10 KB/s aus einer Zielanwendung extrahiert, mit Meltdown sind sogar 500 KB/s möglich. (Quelle: Das bedeuten Spectre und Meltdown für die Praxis )
Der Intel-Bug ist schwerwiegender, weil die Daten viel schneller gelesen werden können. Mit Spectre ist es dann doch etwas zäher. Problem ist bei beiden, dass entsprechende Prozesse so lange dafür Zeit haben, wie sie eben laufen. Auf Servern ein Spaß, im Privatbereich nun ja... viel Spaß beim Scannen mit 10KB/s.
 
Ist für den Haswell-e das aktuellste Microcode-Update die 3B? Eine andere hab ich im neusten Update nicht gefunden. Ist da auch schon das Patch für Spectre drin? Weiß das jemand zufällig?
 
Ist für den Haswell-e das aktuellste Microcode-Update die 3B? Eine andere hab ich im neusten Update nicht gefunden. Ist da auch schon das Patch für Spectre drin? Weiß das jemand zufällig?

So wie ich das sehe, sind die Haswell-E und Broadwell-E noch nicht gepacht. Zumindest die E5 XEON's.

Bin mir nicht ganz sicher. Ich habe das anhand vom C612 Chipsatz und einem E5 v4 XEON ermittelt. Wenn Du mir Dein Board und Deine CPU mit CPU ID, Stepping und die uCU Version nennst, kann ich das ermitteln. Die Infos liefert HWiNFO64.

Es müsste folgende Datei sein (ohne Gewähr):

cpu000306f2_plat0000006f_ver0000003b_date20171117.bin

Wenn das Deine CPU ID ist (000306f2), dann ist da noch gar nichts gepacht bei 3b. Es gibt auch noch keine aktuellere Version z.Z.

Haswell-E-uCU-1.PNG

Haswell-E-Brodwell_E-uCU-1.PNG

Weitere Infos hier:

BIOS mit uCodes patchen (Meltdown und Spectre)
 
Zuletzt bearbeitet:
Durch den Bug ist es eben doch moglich, aus dem Gast auf den Host zuzugreifen.
Der Grund warum erstmal viele vServer Anbieter panisch auf Patches gewartet haben denn: Im Grunde alle VM Host nutzen die Virtualisierungstechnik der Prozessoren

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

Ist für den Haswell-e das aktuellste Microcode-Update die 3B? Eine andere hab ich im neusten Update nicht gefunden. Ist da auch schon das Patch für Spectre drin? Weiß das jemand zufällig?

1 Microcode von der Intelwebseite runterladen und auspacken. Dann in die Release Note Datei schauen, ob Kürzel Deiner CPU dabei.
2 Im Zweifel mit dem VMware Tool Microcode laden und schauen ob, bei Powershell Check Hardware Part nun grün.
(VMware Tool fixt nicht, da Microcode zu spät geladen, daher Bios Update nötig aber für diese Test ist es ausreichend. Wie das alles geht, ist weiter oben erkärt.)
 
Zuletzt bearbeitet:
@AliManali Es müsste diese Datei sein. Danke.

@Marcellus5000 Update hab ich von Intel schon heruntergeladen. Ich hab gestern ein neues BIOS per UBU gepacht (aber noch nicht geflasht). Da ist mir eben aufgefallen dass es die 3B ist.
 
@Marcellus5000 Update hab ich von Intel schon heruntergeladen. Ich hab gestern ein neues BIOS per UBU gepacht (aber noch nicht geflasht). Da ist mir eben aufgefallen dass es die 3B ist.

Du kannst das wie gesagt mit dem VMware Tool + MS Powershell Script verifizieren:

Hier ist es nochmal easy erklärt:
Intel kämpft mit schwerer Sicherheitslücke (Update: Intel liefert Microcode aus) - Seite 44

Es reicht aber bei Intel, sich an den Reiter Instructions zu halten VMware CPU Microcode Update Driver
Denn die install.bat (habe mal kurz rein geschau) prüft nur die diese beiden AMD Files aus Punkt 2, die müßen auch bei einem Intel Blech da sein, damit das Script nicht mit einem Fehler aussteigt.

Nach dem die install.bat (mit Adminrechten) gelaufen ist und rebootet wurde, mit den Hinweisen/dem Screenshot aus Summary VMware CPU Microcode Update Driver
schauen, was der Treiber so im System Event Log von Windows erzählt.

"The driver will report its actions in the OS’s event log that can be examined using “Event Viewer”. The driver reports whether it found supported processors and if an update was attempted or successfully performed on a processor"

Mit der uninstall.bat dann wieder zurück bei Problemen (plus Reboot).

...

Mit dem Check von MS prüfen, ob der Punkt "Hardware support for branch target injection mitigation is present" mit dem neuen Microcode nun auf "True" steht.
(siehe hier https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in?ranMID=24542&ranEAID=hL3Qp0zRBOc&ranSiteID=hL3Qp0zRBOc-dLUp0HtsD6if1cnT2zQaQA&tduid=(f813c7a6faaab9187ed9da9206929ad7)(256380)(2459594)(hL3Qp0zRBOc-dLUp0HtsD6if1cnT2zQaQA unter "PowerShell Verification using the PowerShell Gallery")
 
Zuletzt bearbeitet:
@Marcellus5000 Update hab ich von Intel schon heruntergeladen. Ich hab gestern ein neues BIOS per UBU gepacht (aber noch nicht geflasht). Da ist mir eben aufgefallen dass es die 3B ist.

Was hat Dein entpacktes BIOS für eine Dateiendung? Konntest Du der fertig gepachten BIOS.bin Deine Endung verpassen (siehe in meinem Guide am Schluss)? Wenn ja, wie?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh