Microcode

Dieser Artikel oder Artikelabschnitt ist noch nicht vollständig!

---

Einige Prozessoren erlauben es, den Firmware-Code (oder auch Microcode genannt) beim Systemstart zu überschreiben, so dass ohne ein BIOS-Update eventuelle Firmware-Fehler beseitigt werden können. Das Überschreiben gilt aber nur bis zum Ausschalten des Computers (es ist reversibel), so dass danach wieder der ursprüngliche Code vorhanden ist.

Unterstützte Prozessoren

Eine Liste mit unterstützten Modellen gibt es sowohl von Intel als auch von AMD.

Microcode-Updates aktivieren

Für AMD-Prozessoren befindet sich alles Nötige in dem Paket linux-firmware, welches bereits installiert sein sollte.

Intel-Benutzer müssen das Paket intel-ucode installieren.

Aktivieren von Intel Microcode-Updates

Achtung: Seit der Kernelversion linux 3.17-2 bzw. linux-lts 3.14.21-2 werden Intel Microcode-Updates nicht mehr automatisch angesteuert und müssen manuell aktiviert werden.

Die Updates werden durch Hinzufügen von /boot/intel-ucode.img als ersten initrd-Befehl in der Bootloader-Konfiguration erreicht.

Beispiele

EFI Stub Kernel

Man fügt zwei initrd-Befehle hinzu:

initrd=/intel-ucode.img initrd=/initramfs-linux.img

Gummiboot

Man benutzt die initrd-Option zweimal in dem unter /boot/loader/entries/ für Arch Linux vorgesehenen Eintrag:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options ...

Grub

Bisher hat das Arch Linux Entwickler-Team noch nicht entschieden, wie es mit Microcode-Updates bei Grub verfahren möchte (s. a. im Bug FS#42354. Bis dahin kann man sich mit zwei Notlösungen verhelfen.

Möglichkeit 1: Editieren der grub.conf

Man editiert die Datei /etc/grub.conf und fügt zu jedem dort gelisteten Eintrag entweder /intel-ucode.img, falls man eine extra Boot-Partition besitzt, oder /boot/intel-ucode.img, falls man keine spezielle Boot-Partition verwendet, hinzu.

[...]
echo	'Loading initial ramdisk ...'
initrd	/intel-ucode.img /initramfs-linux.img
[...]

Achtung: Mit jedem Update von GRUB wird diese Datei überschrieben, so dass anschließend die Änderungen erneut vorgenommen werden müssen.

Möglichkeit 2: Editieren der /etc/grub.d/10_linux

Man bearbeitet die Datei /etc/grub.d/10_linux, von der aus die grub.conf erstellt wird, und fügt die mit + beginnenden Zeilen hinzu. Anschließend entfernt man die mit - beginnenden Zeilen:

   if test -n "${initrd}" ; then
+    if test -f "${dirname}/intel-ucode.img"; then
+        ucode="${rel_dirname}/intel-ucode.img"
+    else
+        ucode=
+    fi
     # TRANSLATORS: ramdisk isn't identifier. Should be translated.
     message="$(gettext_printf "Loading initial ramdisk ...")"
     sed "s/^/$submenu_indentation/" << EOF
 	echo	'$(echo "$message" | grub_quote)'
-	initrd	${rel_dirname}/${initrd}
+	initrd	${ucode} ${rel_dirname}/${initrd}
 EOF

Anschließend generiert man die grub.conf neu:

# grub-mkconfig -o /boot/grub/grub.cfg

Hinweis: Bei dieser Methode kann es dazu kommen, das eventuelle GRUB-Updates nicht richtig installiert werden

Syslinux

Man kann hier verschiedene initrd-Einträge durch Kommas trennen. Dazu bearbeitet man die Datei /boot/syslinux/syslinux.cfg:

LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux
    INITRD ../intel-ucode.img,../initramfs-linux.img
    APPEND ...

Feststellen, ob Microship-Updates vorgenommen wurden

Möchte man nun überprüfen, ob beim Booten des Systems ein Microship-Update stattgefunden hat, so kann man dies durch Eingabe von dmesg tun. Ein positives Ergebnis bei einem Intel-Prozessor sollte wie folgt aussehen:

[    0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
[    0.221951] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29
[    0.242064] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29
[    0.262349] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29
[    0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b
[    0.507335] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Verwendet man neuere Hardware, kann es vorkommen, dass trotz richtiger Konfiguration kein Microship-Update vorgenommen wurde, da der Prozessor bereits auf dem neusten Stand ist. In diesem Fall erhält man eine solche Ausgabe:

[    0.292893] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c
[    0.292899] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c
[    0.292906] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c
[    0.292912] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c
[    0.292956] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Bei AMD-Prozessoren findet das Microship-Update erst etwas später im Bootprozess statt. Deshalb erhält man ein Ergebnis wie dieses:

[    0.807879] microcode: CPU0: patch_level=0x01000098
[    0.807888] microcode: CPU1: patch_level=0x01000098
[    0.807983] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   16.150642] microcode: CPU0: new patch_level=0x010000c7
[   16.150682] microcode: CPU1: new patch_level=0x010000c7