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

[Marcellus5000]

Ja MBR kein GPT (GPT 4 TB Platte als Datengrab verbaut aber nicht in der Bootchain) Ansonten Dualboot mit Windows 7 und 10. Läuft über den Windows Bootloader im UEFI festgelten MBR der SDD.
DVD Laufwerk und USB kommen im UEFI von der Bootreihenfolge vor der SSD.

 

[MAG66]

Dann probiere das erst einmal mit der unveränderten cfg aus, also mit dem Grub-Menü.
Nach dem Laden des Menüs sinngemäß Folgendes ausführen:

1. Microcode laden
2. MBR auswählen - dann sieht man ja, was gestartet wurde

 

[Marcellus5000]

Dann probiere das erst einmal mit der unveränderten cfg aus, also mit dem Grub-Menü.
Nach dem Laden des Menüs sinngemäß Folgendes ausführen:

1. Microcode laden
2. MBR auswählen - dann sieht man ja, was gestartet wurde

Ja OK thx. Soweit im Trockenschwimmen klar aber wie automatisiere ich über die toplevel.cfg? War mal RHCE aber bin schon 10 Jahre raus aus Linux, bzw. nutze das auf der Arbeit täglich aber nie so tief (SAP Basis Admin).
Eine Referenz toplevel.cfg würde mir helfen, um quasi via Reverse Engineering mäßig meine Schlüße zu ziehen. Den Rest bekomme ich dann schon "gebacken".

 

[Ceiber3]

Muss also immer der Stick dafür drin bleiben ? Wenn ja, warte ich lieber auf ein Bios Update.

 

[MAG66]

Ich verwende noch nicht einmal ein "PC"-Linux. Meine letzten Linux-Erfahrungen waren aus den 90ern. Man muss ja mit solchen Aussagen vorsichtig sein - Fast jeder verwendet ein Linux-Derivat (z. B. Android).
Wie auch immer - Ich habe mir an diesem einen Tag die relevanten Teile der Grub-Doku durchgelesen und mir dann etwas zusammen gebastelt.

In dem o.g. cfg Ordner befindet sich die Standard toplevel.cfg und auch noch weitere relevante cfg Dateien. Für Anregungen sollte man sich die configure.cfg (insb. mcu_load ...) und u.U. die boot.cfg mal ansehen.
Das Ergebnis muss dann in die toplevel.cfg ...

- - - Updated - - -

Das der Stick am Rechner bleibt, ist belanglos. Das Problem was ich sehe, ist, dass es für viele Boards keine Firmware-Updates geben wird. U. U. gibt es noch nicht einmal ein Microcode-Update für die Core 2 Reihe (habe hier noch einen Q9550).

Falls (hd1) die korrekte Partition sein sollte (siehe dbzgl. auch "Boot first drive MBR" usw. in der boot.cfg), dann sollte das Folgende in der toplevel.cfg ausreichen:

echo "Starting BITS ..."

if [ -e /boot/cfg/init.cfg ]; then source /boot/cfg/init.cfg; fi
if mcu_load /boot/mcu; then exit; fi

 

[kroxx]

@kroxx, eine Frage. Am Montag kommt wohl ein gepatchter Kernel für Ubuntu 16.04.3 heraus, der den Intel-Microcode gegen Spectre läd. Wird der jedes mal geladen, oder kann man das im Dual-Boot nutzen, und der Microcode befindet sich nach einmaligem Laden per Linux-Kernel im Flash des BIOS und fixt so die CPU-Fehler, auch für das Dual-Boot-Windows, in meinem Fall leider Windows 7?

Der wird jedes Mal auf's Neue durch den Bootloader (i. d. R. "Grub") geladen: https://wiki.archlinux.de/title/Microcode
Permanent geht nicht! Lies mal, was MAG66 hier im Thread dazu schreibt.

Ich habe ein Gigabyte Q77M-D2H-Board mit Intel i5 3475S CPU. Ich befürchte, dass es dafür kein BIOS-Update geben wird.

Wohl kaum. Im Prinzip stimme ich MAG66 zu, dass BIOS-Modding heikel ist. Unterstützt Dein Board "GIGABYTE DualBios"? Dann könntest Du es trotzdem riskieren. Ist ja schließlich ein Notfall. Wenn Du ein Neuling sowohl bei Linux als auch beim BIOS-Modding bist, dann ist es definitiv leichter, mit UBU das BIOS upzudaten. Zumal bei Ivy Bridge / der 7er Serie nichts Besonderes zu beachten ist. Aber bitte vorher genau lesen:
https://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html

 

[Medi Terraner]

@MAG66 Danke für den Hinweis bzw. die Links.

 

[floogy]

Der wird jedes Mal auf's Neue durch den Bootloader (i. d. R. "Grub") geladen: https://wiki.archlinux.de/title/Microcode
Permanent geht nicht! Lies mal, was MAG66 hier im Thread dazu schreibt.

Danke, habe das schon gesehen und das Laden per GRUB (Bits) interessiert verfolgt. Da ich schon GRUB verwende, sehe ich mich mal nach einem HOWTO für dessen Konfiguration um, bin dem Arch-Link noch nicht gefolgt. Ich werde dann später hier berichten.

 

[Marcellus5000]

In dem o.g. cfg Ordner befindet sich die Standard toplevel.cfg und auch noch weitere relevante cfg Dateien. Für Anregungen sollte man sich die configure.cfg (insb. mcu_load ...) und u.U. die boot.cfg mal ansehen.
Das Ergebnis muss dann in die toplevel.cfg ...

Falls (hd1) die korrekte Partition sein sollte (siehe dbzgl. auch "Boot first drive MBR" usw. in der boot.cfg), dann sollte das Folgende in der toplevel.cfg ausreichen:

echo "Starting BITS ..."

if [ -e /boot/cfg/init.cfg ]; then source /boot/cfg/init.cfg; fi
if mcu_load /boot/mcu; then exit; fi

hd1 ist korrekt aber mit Deinem Eintrag bootet das System bei mir in Schleife.

Ich habe stattdessen nun folgendes die toplevel.cfg konfiguriert:

if [ -e /boot/cfg/init.cfg ]; then source /boot/cfg/init.cfg; fi
if mcu_load /boot/mcu; then configfile /boot/cfg/boot.cfg; fi

Nun muß ich noch manuell auswählen, von welcher HD ich booten will. Aber der Microcode wird automatisch geladen.
Da es der erste Eintrag im Menü ist, muß ich also nur einmal Enter drücken und er bootet die erste HD. Da kann ich vorerst auch mit leben.

Eigentlich erschien es mir logisch, die /boot/cfg/boot.cfg wie folgt zu modifizieren, um das mit der Enter Taste zu vermeiden:
set root=(hd1)
drivemap (hd1) (hd0)
chainloader +1

Aber so will er nicht. Naja mal sehen, vielleicht lese ich mir die Grub Doku nochmal in Ruhe durch aber für heute ist erst einmal gut.

Ansonsten funktioniert das mit dem Microcode Update gut udn der Powershell Check ist nun grün:

Ohne USB Stick:

Mit USB Stick:



Vielen Dank für Deine Hilfe

 

[GorgTech]

Ich bin ebenfalls dabei, das Bios eines MSI Z170A Gaming Pro Carbon zu modifizieren weil ich ehrlich gesagt nicht mit einem weiteren Update rechne.

Die Informationen in diesem Thread sind sehr nützlich

 

[Medi Terraner]

Ich hab versucht, die BITS mittels YUMI auf einem Stick zu installieren. Hat aber nicht geklappt. Musste die Syslinux.cfg ändern. Aber jetzt findet er die normal.cfg im i386_PC nicht. Wo ich das ändern kann, hab ich noch nicht gefunden. Wenn ich es wie in der install.txt mache, funktioniert es.
Neuerdings funktioniert die Überprüfung von Spectre/Meltdown nicht mehr per Powershell. Irgendeine Richtlinie kann nicht geändert werden...

 

[floogy]

Ich habe nun gelesen, dass für Windows 7 KB4056894, vielleicht auch KB4056897 den intel-microcode mitbringen. Merkwürdigerweise wurde bei mir nun schon zum dritten mal KB4056894 installiert:

_________

KB4056897 habe ich manuell über den update-katalog installiert, es wurde mir trotz des passenden DWORD reg code nicht angezeigt.
Get-SpeculationControlSettings sowie InSpectre.exe ergeben vorher wie nachher, dass Spectre nicht geschlossen ist.

Ich dachte, mit dem KB4056894 würde der intel-microcode geladen, und ich könnte auf die Anpassung meines GRUB verzichten?

„Im Security-Only-Patch KB4056897 gibt es ebenfalls keine Microcode-Updates (mcupdate_Genuine.dll).
Aber im Rollup KB4056894 sind die Microcode-Updates enthalten.“ Bolko, 5. Januar 2018 um 16:26
Windows 7: Sicherheitsupdate KB4056894 verfgbar | Borns IT- und Windows-Blog

Bezüglich GRUB weiß ich nicht, ob ich dort das os-prober Skript anpassen könnte, so dass die grub.cfg für das Laden des ucodes, bevor Windows geladen wird, richtig erstellt wird. Oder kann GRUB das gar nicht, sondern nur BITS?

 

[MAG66]

@Medi Terraner
Bzgl. der Richtlinie:
1. Starte bitte mal eine Eingabeaufforderung mit "Als Admin... ausführen".
2. Dort powershell eingeben und ausführen.
3. In der Shell Get-ExecutionPolicy -list eingeben und ausführen.

Sieht die Ausgabe u. U. wie folgt aus?

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser AllSigned oder Restricted
LocalMachine Undefined


Falls ja, dann musst du Folgendes eingeben und ausführen:

Set-ExecutionPolicy RemoteSigned -Scope Currentuser

Punkt 3 bitte wiederholen - Die Ausgabe sollte jetzt wie folgt aussehen:

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Undefined


Jetzt sollte das Script wieder funktionieren.

 

[floogy]

Die Aussage im Zitat Bolkos, dass „im Rollup KB4056894 sind die Microcode-Updates enthalten“ sein soll, stimmt wohl doch nicht. Es ist wohl auch nicht von Microsoft geplant.

Übrigens macht das Microcode-Update-Problem die Microsoft-Updates für Windows zu Spectre zumindest zu einem großen Teil sinnlos, weil kaum ein Benutzer für seine Hardware ein BIOS-Update erhalten wird, geschweige denn die Mehrzahl der Normal-Anwender in der Lage sein wird ein solches einzuspielen. Man kann das im KB-Artikel zu dem Patch lesen, in dem steht, daß zum vollständigen Funktionieren des Patches ein Microcode-Update erforderlich ist, Microsoft aber nur für Surface-Laptops eines bereitstellen wird.

Re: Micro-Code Update? | Forum - heise online

Daher ist nun BITS oder GRUB (os-prober, 41-custom) wieder von Interesse.

 

[MAG66]

@floogy
Mit BITS funktioniert es. Ich habe auch die microcode.dat und nicht die ucodes in den boot\mcu Ordner eingefügt.
Ich bezweifel, dass MS die Microcodes überhaupt liefert. Die Microcodes werden von Intel bzw. AMD erstellt und gehen dann an die Boardhersteller ...

 

[Marcellus5000]

Bezüglich GRUB weiß ich nicht, ob ich dort das os-prober Skript anpassen könnte, so dass die grub.cfg für das Laden des ucodes, bevor Windows geladen wird, richtig erstellt wird. Oder kann GRUB das gar nicht, sondern nur BITS?

Es ist ja kein normaler Grub, sondern imo mit den Pyton Scripten von BITS verschachtelt. Die Grub Konfig habe ich jedenfalls aus meinen Linux Zeiten (vor ca. 5000 Jahren anders in Erinnerung.

 

[Poddy]

Ich habe jetzt mal auf meinem Dual-Boot-System mit opensuse/ Win7 in opensuse alle updates installiert und dann noch zusätzlich den aktuellen Kernel. Die Microcodes sind auf dem aktuellen Stand für meinen 3770K - v20180108.
Da schaut es jetzt so aus:

Passwort:
localhost:/ # cd /tmp/spectre-meltdown-checker
localhost:/tmp/spectre-meltdown-checker # sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities against running kernel Linux 4.14.13-1-default #1 SMP PREEMPT Wed Jan 10 09:14:27 UTC 2018 (bd444a0) x86_64
CPU is Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (77 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: NO
* The SPEC_CTRL CPUID feature bit is set: NO
* Kernel support for IBRS: YES
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Checking if we're running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
localhost:/tmp/spectre-meltdown-checker #

Unter Windows will nach der Installation von PowerShell 6, Management Framework und NuGet, das SpeculationControll-Modul immer noch nicht richtig funktionieren:

Hat jemand nen Rat?

 

[Marcellus5000]

Ich kenne die Lösung nicht aber ich bewundere Dein Problem. Spaß beiseite, die Fehleleung Meldung ist auf jeden Fall strange. Als wäre das nicht richtig installiert. Ggf. liegt es an der 6er Version. Mein Windows 10 hat die 5 installiert.

PS C:\Users\Master>
>> $PSVersionTable.PSVersion

Major Minor Build Revision
----- ----- ----- --------
5 1 16299 98


Ansonsten kannst Du mal probieren, das Script/Modul manuell runterzuladen und einzubinden. Ggf. klappt das ja. https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in?ranMID=24542&ranEAID=hL3Qp0zRBOc&ranSiteID=hL3Qp0zRBOc-fy5Cadp9Z6kdRfsQ_UlpMw&tduid=(89564fda1d921d53f215c72276f26606)(256380)(2459594)(hL3Qp0zRBOc-fy5Cadp9Z6kdRfsQ_UlpMw)()
(Ab PowerShell Verification using a download from Technet (earlier operating system versions and earlier WMF versions))

 

[Poddy]

Das hatte ich schon versucht und ging nicht. Jetzt hab ich das aber nochmal mit der alten Powershell versucht wo Anfangs gar nichts ging und siehe da, es geht. Danke.



Aber irgendwie scheint der Microcode unter Win nicht zu greifen - so wie das bei MAG66 funktioniert.

 

[floogy]

@Poddy, Was sagt denn InSpectre.exe von GRC

microcode 1B, Installation der microcode.dat per vmware-tool aus 20180108.tgz

Neues scannen mit HWINFO64: microcode 1C

Inzwischen glaube ich auch fast, dass mit dem Microcode bei meiner CPU etwas nicht stimmt. Unter Windows habe ich den erfolgreich upgedatet von µCU 1B auf µCU 1C. 1C kommt mir da allerdings auch von Linux bekannt vor. Dort ergibt das Skript ebenfalls, dass Spectre nicht geschlossen ist. Meine ist i5-3475S.

Verwendet habe ich VMware CPU Microcode Update Driver und 20180108.tgz

 

[kroxx]

@floogy & Poddy

Das kann auch (noch) nicht funktionieren! Der Microcode für Ivy Bridge ist doch noch gar nicht aktualisiert worden (nur Ivy Bridge E). Im Paket vom 08.01.2018 sind nur schon einmal Platzhalter für alle Prozessoren enthalten.
MAG66 & Marcellus5000 haben jeweils einen Haswell: Dessen MC wurde am 08.01.2018 tatsächlich aktualisiert.

Also ... Geduld

 

[Marcellus5000]

Aber irgendwie scheint der Microcode unter Win nicht zu greifen - so wie das bei MAG66 funktioniert.

Gerne. Also bei mir klappt es auch:

Ohne USB Stick:
Anhang anzeigen 425112
Mit USB Stick:
Anhang anzeigen 425113

Was sagt der Boot Stick denn, wenn Du das Update des Microcodes auswählt (Bei mir sowas wie "updatet 4 of 8 CPUs", ich sehe die Melung ja nicht mehr.)?
Also nur nochmal zur Sicherheit: Es reicht nicht aus, erst das Open Suse via Multiboot zu booten und dann Windows. Du müßtest schon den Stick nutzen.

 

[Poddy]

@Marcellus
Sicher? Ich habe kein Stick, sondern normales Dual-Boot-System. Aber das sollte doch egal sein, denn der Microcode wird doch mir grub geladen und nicht erst wenn ich Linux starte, oder?

@kroxx
Aber unter Linux scheint ja alles zu passen und der Microcode zu greifen und für Spectre Variant 2 gibts glaub noch kein Fix, oder? Bug 1068032

Ganz schön konfus die Sache.

- - - Updated - - -

@floggy
Auf so ein Tool will ich lieber verzichten und bringt es etwas den Microcode unter Windows upzudaten ?

 

[floogy]

@floogy & Poddy

Das kann auch (noch) nicht funktionieren! Der Microcode für Ivy Bridge ist doch noch gar nicht aktualisiert worden (nur Ivy Bridge E). Im Paket vom 08.01.2018 sind nur schon einmal Platzhalter für alle Prozessoren enthalten.
MAG66 & Marcellus5000 haben jeweils einen Haswell: Dessen MC wurde am 08.01.2018 tatsächlich aktualisiert.

Also ... Geduld

Achso!! Danke! omg.

@Poddy, also ich bekomme mit dem Skript unter Linux das gleiche Ergebnis für Spectre v1 v2 Vulnerable. Habe aber einen aktuellen Kernel 4.4.0.109.114 und die aktuellen microcodes installiert (dmesg | grep micro listet auch was mit 1c, muss ich noch mal rebooten). Allerdings sagte man mir, dass der Kernel noch nicht aktuell genug ist. Einige Optionen stimmen wohl noch nicht. Ich reboote und poste mal die Linux-Ausgaben.

 

[kroxx]

Ganz schön konfus die Sache.

Nicht die Sache, sondern die Meldungen auf hardwareLUXX

 

[Poddy]

Ich hab da glaub auch was durcheinanderer gebracht. Für den Variarant 2 unter dem Linux-Checker braucht es den Microcode richtig?
Dann heisst das wohl noch abwarten.

 

[Medi Terraner]

@MAG66 Danke für den Tipp zwecks PS. Hat geklappt.
PS zeigt mir nun:


Allerdings sagen InSpectre und Spectre Meltdown CPU Checker immer noch YES bei Spectre...

 

[floogy]

Hier noch ein paar Links:
https://www.heise.de/newsticker/meldung/Bug-in-aktuellen-Intel-Prozessoren-macht-die-Runde-3755660.html
Microcode einspielen leicht gemacht (Anleitu | Forum - heise online

Ich erweitere diesen Post dann gleich noch mal um die Linux-Ausgaben.

Hier die Ausgaben für einen älteren Kernel, der keinen microcode nachläd: show at bpaste
[ 0.751219] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x10

Hier die Ausgaben für den aktuellen Kernel, der wohl doch microcode nachläd, aber eben nicht mit den spectre/meltdown patches für ivy bridge: show at bpaste
microcode : 0x1c
[ 0.081957] microcode: CPU3 microcode updated early to revision 0x1c, date = 2015-02-26
[ 0.862253] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1c


Ich denke aber langsam auch, dass der Microcode noch nicht für unsere i5 Ivy Bridge CPUs fertig ist.

 

[Marcellus5000]

@Marcellus
Sicher?

Ziemlich aber testen kann ich es nicht. Du ja auch noch nicht.

- - - Updated - - -

@floogy: Das VMware Tool (Heise Link) funktioniert bei Spectre nicht, da es zu spät einsetzt. Es eignet sich nur für einen Schnelltest, ob der Microcode Spectre fixen würde.

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

 

[floogy]

Das soll scheinbar optimiert werden:
Re: Geht nicht | Forum - heise online

Offenbar muss ich auf microcode für IvyBridge warten und eine Lösung für Grub finden, eventuell eine Optimierung des os-prober Skripts, damit dort die Zeile zum Laden des microcode-images ind die grub.cfg beim Menüeintrag Windows geschrieben wird.