[Sammelthread] Intel Microcodes patchen - mod BIOS - uCodes Bootloader - OS Patch - Spectre II

Warum wartet ihr nicht einfach bis alle Fehler bereinigt sind und flasht dann erst den Code ? Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück

Die Meldung ist von Gestern 20:18 Uhr.

- - - Updated - - -

Aus welchen Gründen auch immer, habe ich große Probleme mit BITS.
Ich nehme an, das liegt daran, dass ich statt EFI noch die legacy BIOS-Einstellung des Boards verwende und statt gpt msdos Partitionen verwende.

BITS erkennt auch nicht load_mcu und status_mcu

Ich würde das gerne zum Laufen bringen, damit ich vorbereitet bin für die passenden kommenden microcodes.

Ich habe in die boot.cfg von BITS nun mal die vorher verwendete grub.cfg meines Linux-Dual-Boot verwendet. Es gehen aber nur die Linux-Eintrage, Das Chainloading Openindianas und die original Windows-Einträge der bestehenden GRUB2 Installation (die sonst, ohen BITS, funktionieren) gehen nicht mehr.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aus welchen Gründen auch immer, habe ich große Probleme mit BITS.
Ich nehme an, das liegt daran, dass ich statt EFI noch die legacy BIOS-Einstellung des Boards verwende und statt gpt msdos Partitionen verwende.

Ist bei mir auch so. (Also das ich die legacy BIOS-Einstellung nutze).
Du meinst vermutlich MBR mit "msdos Partitionen" (Du kannst MBR auch mit Linux etc. nutzen, das hat nichts mit dos zu tun).
Es ist bei mir ebenfalls so, das ich MBR nutze (Für die hier relevante OS Disk/SSD. GPT nutze ich nur beim 4 TB Datengrab).

- - - Updated - - -

Warum wartet ihr nicht einfach bis alle Fehler bereinigt sind und flasht dann erst den Code ? Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück

Die neuen MC geflasht hat hier bis jetzt imo noch keiner. BITS ist nicht permanent.
 
Zuletzt bearbeitet:
MBR verstehe ich als Abkürzung für Master Boot Record, das ist der Bootsektor früherer Partitionierungen nach dem msdos Schema gegenüber GPT Partitionsschema GUID-Partitionstabelle. Seit 2010 wird mit MBR auch das msdos Partitionsschema bezeichnet, ist also synonym/gleichbedeutend.

Das sieht hier so aus:
Code:
#https://wiki.gentoo.org/wiki/GRUB2/Chainloading
menuentry 'Windows 7 (loader) (auf /dev/sde1)' --class windows --class os $menuentry_id_option 'osprober-chain-01D2D18DE1A77E10' {
	insmod part_msdos
	insmod ntfs
        insmod ntldr
	insmod chain
	set root='hd4,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd4,msdos1 --hint-efi=hd4,msdos1 --hint-baremetal=ahci4,msdos1  01D2D18DE1A77E10
	else
	  search --no-floppy --fs-uuid --set=root 01D2D18DE1A77E10
	fi
	parttool ${root} hidden-
	#drivemap -s (hd0) ${root}
	#map (hd0) (hd4)	
	#map (hd4) (hd0)	
	#makeactive
	chainloader (hd4,msdos1)+1
}

Wobei drivemap, map, makeactive nicht funktionieren. Wahrscheinlich sind sie a) aus BITS entfernt, oder/und b) nicht mehr aktuell in GRUB2. Ich habe sie daher mit '#' auskommentiert.

drivemap.mod, mmap.mod, partmap.lst etc. sind zwar auf dem Stick, aber die auskommentierten Befehle werden mit einem Fehler "can't find command" quittiert.

Im Vergleich zum funktionierendem GRUB habe ich
insmod ntldr
insmod chain
chainloader (hd4,msdos1)+1
hinzugefügt, bzw. die chainloder Zeile war vorher chainloader +
Die auskommentierten Zeilen waren vorher nicht da.

Im funktionierenden GRUB sieht das so aus:
Code:
menuentry 'Windows 7 (loader) (auf /dev/sde1)' --class windows --class os $menuentry_id_option 'osprober-chain-01D2D18DE1A77E10' {
	insmod part_msdos
	insmod ntfs
	set root='hd4,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd4,msdos1 --hint-efi=hd4,msdos1 --hint-baremetal=ahci4,msdos1  01D2D18DE1A77E10
	else
	  search --no-floppy --fs-uuid --set=root 01D2D18DE1A77E10
	fi
	parttool ${root} hidden-
	chainloader +1
}

Wahrscheinlich führt das aber in diesem Thread zu weit. Sollte ich dafür eventuell einen neuen eröffnen?
Hat jemand Tipps wo ich so etwas am Besten diskutieren könnte, bzw. Unterstützung bekommen könnte? Für BITS gibt es da ja nicht so viel.

Einfachere Layouts, wie das hier, funktionieren auch nicht:
Code:
menuentry "Boot hd4 drive MBR" {
    insmod part_msdos
    insmod chain
    set root=(hd4,msdos1)
    chainloader +1
}
menuentry "Boot fourth drive MBR" {
    insmod part_msdos
    insmod chain
    set root=(hd4,msdos1)
    drivemap (hd4) (hd0)
    chainloader +1
}

PS.: Der neue Kernel kommt gerade herein: linux-image-4.4.0-112-generic, aber es lag ja eher am microcode ohne code für variante #2, dass spectre 2 noch als VULNERABLE erkannt wurde ... Obwohl der reptoline wohl ohne microcode auskommt?

Wenn ich das mit BITS nicht hinbekomme, weder Microsoft noch VMWare es hinbekommen den korrekten µcode früh genug auf die CPU zu laden und GIGABYTE kein BIOS-Update für Q77M-D2H herausbringt, werde ich Windows 7 wohl ungepatcht weiterbetreiben müssen.
 
Zuletzt bearbeitet:
MBR verstehe ich als Abkürzung für Master Boot Record, das ist der Bootsektor früherer Partitionierungen nach dem msdos Schema gegenüber GPT Partitionsschema GUID-Partitionstabelle.
Seit 2010 wird mit MBR auch das msdos Partitionsschema bezeichnet, ist also synonym/gleichbedeutend.

OK 1 zu 0 für Dich. :fresse: Ich nenne den Master Boot Record aber dennoch einfach MBR.
Auch wenn sich Bezeichnung msdos Schema offenbar etbaliert hat, ich finde sie unglücklich gewählt. Man könnte den MBR dann ja auch OS/2 Partition nennen.


Wobei drivemap, map, makeactive nicht funktionieren. Wahrscheinlich sind sie a) aus BITS entfernt, oder/und b) nicht mehr aktuell in GRUB2.

Also in der boot.cfg von BITS wird drivemap zumindest genutzt.

menuentry "Boot first drive MBR" {
set root=(hd1)
drivemap (hd1) (hd0)
chainloader +1
}

Ansonsten (Ist nicht böse gemeint, mir fehlt aktuell ein bisl die Zeit hier alles genau zu lesen), muß ich aber zugeben, den Überblick verlohren zu haben, was Du da genau eigentlich machst und wieso. (Anstatt einfach BITS so zu nutzen wie von MAG66 empfohlen).
 
Zuletzt bearbeitet:
Der Stick wurde immer im UEFI-Modus gestartet. Ich hatte das leider nicht mitbekommen. Wenn ich ihn im BIOS-Bootmenü als legacy SanDisk auswähle, dann funktionieren auch die mcu_load und mcu_status Skripte, auch grundsätzlich die toplevel.cfg, die hier gepostet wurde, auch die boot.cfg. Allerdings gibt es andere Probleme durch die Bootreihenfolge. Die Reihenfolge der Festplatten hat sich dadurch geändert und das reguläre grub ist nun davon betroffen. Auch scheint sich das BIOS diese Reihenfolge nicht zu merken. Vielleicht die Batterie? Muss mir das noch näher ansehen.
 
Der Stick wurde immer im UEFI-Modus gestartet. Ich hatte das leider nicht mitbekommen. Wenn ich ihn im BIOS-Bootmenü als legacy SanDisk auswähle, dann funktionieren auch die mcu_load und mcu_status Skripte, auch grundsätzlich die toplevel.cfg, die hier gepostet wurde, auch die boot.cfg.

@AliManali: Kannst Du das in den Guide aufnemen und meine Anpassung an der boot.cfg?

Gruß und Dank
 
Da ich selbst auch noch Sandy Bridge verwende, schwebt mir inzwischen eine andere Lösung vor als die, den Microcode im BIOS zu speichern: Dual-Boot Windows (ohne Microcode-Update, für die Spiele) / Linux (mit Microcode-Update, für alles andere)
Mache ich davon abhängig, wie sehr die Leistung einbricht. (Erreiche halt jetzt gerade eben noch so die Mindestanforderungen aktueller Spiele. Spielraum ist da keiner mehr.)
Hoffentlich kommt Microsoft dann nicht auch auf die Idee, den Microcode zu laden, so wie das bei Linux z. Zt. ja schon gemacht wird.

Das Dualboot dürfte durch die USB Stick Methode ja obsolete sein (Damit hat man ja einen Ein/Ausschalter.
Für den Teil mit MS habe ich heute etwas gefunden (siehe wushowhide.diagcab):
Windows 10 Updates deinstallieren Deskmodder Wiki
 
Zuletzt bearbeitet:
Ich verstehe, worauf Du hinaus willst: Mit der USB-Stick-Methode diesselbe Windows-Installation mal mit (z. B. zum Surfen) / mal ohne (z. B. zum Spielen) Microcode-Update starten. Das hört sich gut an!
Aber warum willst Du Windows-Updates deinstallieren / blockieren? Das vom 04.01. beinhaltete doch primär den wichtige(re)n Schutz vor Meltdown, und hat bei den meisten - wie auch bei mir - nicht zu spürbaren Leistungseinbußen geführt. Der Schutz vor Spectre, der wohl mehr Performance kosten dürfte, wird ja erst aktiviert, wenn der neue Microcode bereits geladen wurde.
Darum sehe ich eigentlich keine Notwendigkeit, auf Windows-Updates zu verzichten.

Ohnehin scheint mir die ganze Angelegenheit im Moment wieder ziemlich offen zu sein, nachdem Intel die Microcode-Updates zurückgezogen hat. Vielleicht setzt sich ja die "Retpoline"-Lösung durch, und die Antwort sind reine Software-Updates ohne dazugehörige Microcode-Updates.

- - - Updated - - -

Jetzt habe ich es geschnallt: Du hast Dich auf meine Aussage bezogen, dass Microsoft auf die Idee kommen könnte, den Microcode von Windows laden zu lassen. Das müßte man in der Tat dann irgendwie unterbinden.
 
Zuletzt bearbeitet:
Jetzt habe ich es geschnallt: Du hast Dich auf meine Aussage bezogen, dass Microsoft auf die Idee kommen könnte, den Microcode von Windows laden zu lassen. Das müßte man in der Tat dann irgendwie unterbinden.

Ja genau, so war das gemeint. Also eine reine "Was wäre wenn - Überlegung".
Ansonsten ist zur Zeit echt alles offen und es bleibt abzuwarten.
 
Ich habe das wushowhide.diagcab heute mal an einer VM ausprobiert. Funktioniert! Und vorallem kann man das Verstecken des Update auch wieder rückgängig machen.

Was für mich eine wertvolle Erfahrung war, denn unabhängig von Spectre empfand ich es immer als Nachteil, das man bei Windows 10 keine Kontrolle mehr hat, welche Updates eingespiel werden und welche nicht.
Ich erinnere mich noch an Updates, welche Win 10 in Schleife booten liesen (Ich hatte dieses Problem nicht selbst aber las davon). Das könnte eine Lösung sein.
Ich habe nur Win 10 Pro Versionen und kann nicht sagen, ob wushowhide.diagcab auch bei Home funktioniert.
 
Zuletzt bearbeitet:
Hi

Ich habe jetzt den Guide von Post #8 nach #1 verschoben, damit es etwas übersichtlicher wird. Ausserdem habe ich den Threadtitel angepasst und einen Sammler daraus gemacht.
 

Mal schauen was kommt. Ich schau öfter mal hier rein, ob es neue MC zum Download gibt.
Download Linux* Processor Microcode Data File

Ich habe mit dem damals verfügbarem (Spectre gefixten) MC Probleme mit meinen Audio/Gitarre Sachen (Reboots etc aber keine) und werde daher erstmal keinen UEFI Patch einspielen
(Welcher für mein Asrock Z87/Haswell ohenhin nicht vor einem neuem MC kommt).
Ich werde also wieder meinen USB Stick zum Test eines neuen MC nutzen.

Ansonsten bin ich mittlerweile so eingestellt, dass ich wohl im Zweifel dauerhaft mit der USB Stick Lösung fahren werde.
Die Szenarien wo die Lücke relevant ist, sind mir bekannt und dafür kann ich den Stick nutzen. Aber 0815 Usern wie meiner Freundin würde ich das nicht raten.

Ich bin jedenfalls froh, hier Gleichgesinnte gefunden zu haben und gemeinsam Alternativen zu einem UEFI Patch/MS MC Update gefunden zu haben
(So fern der MS Patch denn überhaupt kommt und nur ein MC Update macht, das ist meine größte Sorge).
Vermutlich wird uns das Thema noch länger beschäftigen und so ein Stick ist schnell gezogen und gesteckt.
 
Zuletzt bearbeitet:
Neue MCs (final) für LGA 1155 sind offensichtlich erschienen:

2D für Sandy Bridge CPUID 206A7
1F für Ivy Bridge CPUID 306A9​

Die waren wohl schon am 07.02. fertig und wurden vermutlich seither getestet.
Nur um anderen evtl. die Suche zu ersparen: Ich habe sie (gebrauchsfertig) aus dem aktuellen UBU-Paket "UBU_v1_69_16.7z" ("скача́ть" = herunterladen) - allerdings aus Zeitmangel noch nicht selbst getestet.
 
Auf der Intelseite ist immer noch (auch nicht zu Skylake, welche MS schon hat) nichts als Download zu finden
(Oder ich bin zu doof zu suchen)
Download Linux* Processor Microcode Data File
Downloads for Intel® Core™ Processors

edit:
Ich bin mittlerweile bis zum dem UBU Forum vorgedrungen, dort wird der russische Link auch verwendet und als sicher beschrieben.
Forum - RE: UEFI BIOS Updater Update v1.69.15/1.70 a12 Dev - 248

Ich frage mich aber wieso ich die MCs nicht offiziell von Intel bekommen kann, wie bisher. Und wo die UBU Leute die MCs her haben.
Mit einem Intel Download würde ich mich (Auch wenn Fernando's Win-RAID Forum (Storage Drivers - BIOS Modding) und SoniX nun nicht Irgendwer sind) wohler fühlen.
 
Zuletzt bearbeitet:
Also wäre es hier bald möglich ein UEFI Bios für eine ASUS MVF Platine zu modden? Oder könnte es einer machen?
Denke von ASUS komtm da wie allen Problemen leider nichts...
 
Wenn es microcode updates irgendwann mal gibt, wie werden sie dann installiert, wenn sie nicht mit dem Windows Update geliefert werden?
Muss man sie dann vom Hersteller (in meinem Fall: dell, supermicro und acer) laden?
 
Zuletzt bearbeitet:
Wenn es microcode updates irgendwann mal gibt, wie werden sie dann installiert, wenn sie nicht mit dem Windows Update geliefert werden?
Muss man sie dann vom Hersteller (in meinem Fall: dell, supermicro und acer? laden?

In diesen Thread steht alles nötige an Infos, einfach mal lesen.
 
So, habe jetzt meinem 2600k (CPUID 206A7) den sicher(er)en MC "2D" mit UBU verpasst. "InSpectre" sagt, mein System sei jetzt sicher.:banana:
Das ging echt easy und war dank Gigabyte (AMI Aptio 4) DualBIOS auch keine Mutprobe. Die BIOS ME Region upzudaten war da viel langwieriger und heikler.
Trotzdem habe ich vor dem Flashen Alles doppelt und dreifach überprüft, was die eigentliche Arbeit war: gemoddetes BIOS mit dem MMTool laden, mit dem "MC Extractor" die MCs wieder aus dem gemoddeten BIOS extrahieren und im Hex-Editor mit denen aus dem UBU-MC-Repository vergleichen.
Wie's mit der Performance aussieht, werde ich erst an Ostern sehen, wenn ich wieder Zeit zum Zocken habe.
 
Na dann gz zu Deinem eigenen mod BIOS. :xmas:

Ich bin leider noch nicht so weit. Musste übers Wochenende express eine Dual GPU Workstation aufsetzen und migrieren.

Hast Du jetzt den uCode aus dem UBU Tool verwendet? Ich werd das wohl vorerst mit dem USB Stick lösen, und das erst dann, wenn die uCodes auf der Intel Seite verfügbar sind.

Die BIOS ME Region upzudaten war da viel langwieriger und heikler.

Ist das für den ME Bug? Hast Du das auch mit dem UBU Tool gemacht, und wenn ja in einem Gang mit dem uCodes, bzw. wie denn?
 
Zuletzt bearbeitet:
Mal eine Frage:
Habe heute von Dell für mein Laptop ein neues Bios installiert welches bereits ende Februar als dringend zur Verfügung stand. Wie kann ich jetzt überprüfen, ob dies das Intel Microcode patch update enthielt und ob mein Pc nun sicher ist?
 
OK Danke, ist ein 4720HQ

Sorry das ich nochmal blöd frage, wo zeigt hwinfo64 die CPU ID?

Gemäß der der Intel guidance Liste müsste es die CPU ID 306C3 sein, oder :)
 
Zuletzt bearbeitet:
Hast Du jetzt den uCode aus dem UBU Tool verwendet?
Ja, obwohl ich natürlich auch eine offizielle Quelle bevorzugt hätte.

Ist das für den ME Bug? Hast Du das auch mit dem UBU Tool gemacht, und wenn ja in einem Gang mit dem uCodes, bzw. wie denn?
Ja genau, es ging dabei um die andere Intel-Sicherheitsbaustelle, die ME.
Aber das UBU Tool hilft da nicht weiter. Man kann die ME so updaten wie im Guide beschrieben, den ich verlinkt habe. Im Win-RAID Forum gibt's noch ausführlichere Informationen dazu.
 
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