Microcode: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Zeile 75: Zeile 75:


Bei AMD-Prozessoren findet das Microcode-Update erst etwas später im Bootprozess statt. Deshalb erhält man ein Ergebnis wie dieses:
Bei AMD-Prozessoren findet das Microcode-Update erst etwas später im Bootprozess statt. Deshalb erhält man ein Ergebnis wie dieses:
  [    0.807879] microcode: CPU0: patch_level=0x01000098
  Jul 30 21:59:24 darkstar kernel: microcode: CPU0: patch_level=0x010000c8
  [    0.807888] microcode: CPU1: patch_level=0x01000098
  Jul 30 21:59:24 darkstar kernel: microcode: CPU1: patch_level=0x010000c8
  [    0.807983] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
  Jul 30 21:59:24 darkstar kernel: microcode: CPU2: patch_level=0x010000c8
  [  16.150642] microcode: CPU0: new patch_level=0x010000c7
  Jul 30 21:59:24 darkstar kernel: microcode: CPU3: patch_level=0x010000c8
  [  16.150682] microcode: CPU1: new patch_level=0x010000c7
  Jul 30 21:59:24 darkstar kernel: microcode: Microcode Update Driver: v2.2.
 
[[Kategorie:Hardware]]
[[Kategorie:Hardware]]
[[en:Microcode]]
[[en:Microcode]]

Version vom 30. Juli 2020, 21:04 Uhr

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

systemd-boot (ehemals 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

Möglichkeit 1: grub.conf automatisch

grub.conf automatisch generieren lassen:

#grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image(s) in /boot: intel-ucode.img initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img initramfs-linux-fallback.img
done
# 
Möglichkeit 2: 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.


Syslinux

Man kann hier verschiedene initrd-Einträge durch Kommata 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 Microcode-Updates vorgenommen wurden

Möchte man nun überprüfen, ob beim Booten des Systems ein Microcode-Update stattgefunden hat, so kann einen ersten Test mittels

journalctl -k --grep microcode

durchführen. Im Falle von Intelprozessoren mit erfolgreichem Early Loading erhält man etwa folgendes (hier ein Lenovo Thinkpad T480s):

Sep 04 15:31:40 darkstar kernel: microcode: microcode updated early to revision 0xb4, date = 2019-04-01
Sep 04 15:31:40 darkstar kernel: microcode: sig=0x806ea, pf=0x80, revision=0xb4
Sep 04 15:31:40 darkstar kernel: microcode: Microcode Update Driver: v2.2.

Findet kein Microcode-Update statt, sieht die Ausgaben wir folgt aus (hier das selbe Lenovo Thinkpad T480s):

Jul 30 10:21:06 darkstar kernel: SRBDS: Mitigation: Microcode
Jul 30 10:21:06 darkstar kernel: microcode: sig=0x806ea, pf=0x80, revision=0xd6
Jul 30 10:21:06 darkstar kernel: microcode: Microcode Update Driver: v2.2.

Ein negatives Ergebnis muß nicht auf eine Fehlkonfiguration zurückzuführen sein. Es kann auch bedeuten, daß das BIOS bereits die neueste Firmware enthält. Im Falle des exemplarisch verwendeten T480s war dies nach einem BIOS-Update der Fall. Möchte man sichergehen, daß die neueste Firmwareversion geladen ist, geht man wie folgt vor: Installation von iucode-tool

# pacman -S iucode-tool

Laden des cpuid Kernelmoduls:

# modprobe cpuid

Bestimmung der neuesten Firmware-Revision für die vorhandene CPU:

# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -

Prüfen, ob diese tatsächlich verwendet wird:

grep microcode /proc/cpuinfo

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

Jul 30 21:59:24 darkstar kernel: microcode: CPU0: patch_level=0x010000c8
Jul 30 21:59:24 darkstar kernel: microcode: CPU1: patch_level=0x010000c8
Jul 30 21:59:24 darkstar kernel: microcode: CPU2: patch_level=0x010000c8
Jul 30 21:59:24 darkstar kernel: microcode: CPU3: patch_level=0x010000c8
Jul 30 21:59:24 darkstar kernel: microcode: Microcode Update Driver: v2.2.