Komme mir blöd vor zu fragen aber sind Microcode updates bei EOS bereits per default aktiv? Ich bin ein bisschen verwirrt, da ich zwischen dem Englischen und Deutschen Arch-Wiki-Artikel bzgl. Microcode “widersprüchliche” Aussagen finde.
Im deutschen Wiki steht gleich zu Beginn, dass das Paket linux-firmware für AMD Prozessoren bereits alles nötige enthalten würde. Jedoch werde ich aus dem englischen Artikel nicht schlau, da dort linux-firmware nur unter “Late Loading” auftaucht wovon mittlerweile abgeraten wird. Hat da jemand den Durchblick? Und ist das für Prozessoren die noch Uefi-Updates erhalten überhaupt nötig (wenn man diese ohnehin aufspielt)?
die Aussage ist seit Jahren veraltet, das wiki wird wohl nicht gepflegt. Die AMD-CPU-spezifischen Firmwares sind NUR noch in amd-ucode enthalten, welches erst seit der Ausspaltung existiert.
late loading ist auch schlecht. Der Standard ist early loading über initramfs, wird in EndeavourOS von dracut mit erledigt solange das amd-ucode Paket installiert ist. Die Alternative Lösung ist per grub/systemd-boot, sprich Bootloader
Ja, weil UEFI Updates je nach System-Hersteller verspätet oder nie ankommen können.
Dank dir, das war schnell und einleuchtend. 
Das irritiert mich jetzt.
Wenn ich mir die PKGBUILD beider Pakete anschaue, dann benutzen sie beide die exakt gleiche Quelle:
_tag=20240115
source=("git+https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git#tag=${_tag}?signed")
amd-ucode extrahiert daraus lediglich die amd cpu specifischen Dateien während linux-firmware alles enthält.
linux-firmware enthält also auch die amd cpu specifischen Dateien:
linux-firmware /usr/lib/firmware/amd-ucode/
linux-firmware /usr/lib/firmware/amd-ucode/README.zst
linux-firmware /usr/lib/firmware/amd-ucode/microcode_amd.bin
linux-firmware /usr/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
linux-firmware /usr/lib/firmware/amd-ucode/microcode_amd_fam16h.bin
linux-firmware /usr/lib/firmware/amd-ucode/microcode_amd_fam17h.bin
linux-firmware /usr/lib/firmware/amd-ucode/microcode_amd_fam19h.bin
Demnach sollte das Paket linux-firmware ausreichend sein.
es ist das selbe PKGBUILD für ALLE auf dem linux-firmware Repository - basierten Pakete. Intel macht da ein eigenes Ding, drum ist intel-ucode ein eigenes PKGBUILD und eigenes Repo.
exakt.
nein.
nein.
Das PKGBUILD funktioniert vereinfacht folgendermaßen:
- Checke das Repository aus.
- Packe alles was AMD CPU ist in
amd-ucode - Packe alles was nfp ist in
linux-firmware-nfp - Packe alles was mellanox ist in
linux-firmware-mellanox - alle anderen Split packages nach selbem Muster
- Packe alles was jetzt noch übrig ist in
linux-firmware
Edit: Zumindest sollte es so funktionieren, so war es angekündigt und auch jahrelang umgesetzt. Aber ja, aktuell ist tatsächlich amd-ucode wieder teilweise in linux-firmware mitenthalten, es fehlt allerdings /boot/amd-ucode.img im generischen firmware-Paket um vollständig zu sein. Ich gehe von einem Bug aus.
Für dracut wäre tatsächlich momenten das linux-firmware Paket ausreichend. Für mkinitcpio nicht weil das die Firmware nicht mit ins initramfs packt und damit das bootloader-basierte Loading über amd-ucode.img benötigt.
Edit2: Es wird dran gearbeitet, dass die AMD-CPU-spezifischen Dateien nicht mehr in linux-firmware enthalten sind: https://gitlab.archlinux.org/archlinux/packaging/packages/linux-firmware/-/issues/2
Scheinbar war das dann schon immer so, dass sie in linux-firmware enthalten sind, für mkinitcpio brauchte man aber trotzdem schon immer das amd-ucode Paket.
Ich sehe bei mir aber trotzdem keinen Unterschied.
Ich habe eine alte initrd ohne amd-ucode paket und eine neue initrd mit amd-ucode installiert. Ich extrahiere jeweils die AuthenticAMD.bin:
╰─# cat initrd | cpio -idmv
.
early_cpio
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/AuthenticAMD.bin
79 Blöcke
Und der diff zwischen beiden AuthenticAMD.bin zeigt keinen Unterschied. Wie kann das sein?
Was mich auch irritiert ist, das amd-ucode.img in /boot installiert wird, alle kernel initrd liegen aber in einem unterverzeichn mit der machine_id:
╰─# find
.
./EFI
./EFI/systemd
./EFI/systemd/systemd-bootx64.efi
./EFI/BOOT
./EFI/BOOT/BOOTX64.EFI
./EFI/Linux
./loader
./loader/entries
./loader/entries/4bd88beaa355xxxxxxxxxxxxxxxxxxxx-6.6.13-1-lts.conf
./loader/entries/4bd88beaa355xxxxxxxxxxxxxxxxxxxx-6.6.13-273.2-tkg-eevdf.conf
./loader/entries/4bd88beaa355xxxxxxxxxxxxxxxxxxxx-6.7.0-273.2-tkg-eevdf.conf
./loader/entries/memtest86-efi.conf
./loader/entries.srel
./loader/loader.conf
./loader/random-seed
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-1-lts
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-1-lts/initrd
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-1-lts/linux
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-273.2-tkg-eevdf
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-273.2-tkg-eevdf/initrd
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.6.13-273.2-tkg-eevdf/linux
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.7.0-273.2-tkg-eevdf
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.7.0-273.2-tkg-eevdf/initrd
./4bd88beaa355xxxxxxxxxxxxxxxxxxxx/6.7.0-273.2-tkg-eevdf/linux
./memtest86+
./memtest86+/memtest.efi
./amd-ucode.img
./System Volume Information
Ich hatte das auf Grund der Aussagen in der Wiki vor Monaten auch mal ohne “amd-ucode” ausprobiert. Allerdings wurden alle benötigten Dateien nur korrekt erzeugt und abgelegt, wenn das Paket auch installiert war. Danach habe ich es wieder installiert und nicht weiter nachgeforscht.
Ich habe jetzt aber auch schon öfter gelesen, dass “linux-firmware” / “amd-ucode” sowieso nur den Microcode für die Server und Workstation CPUs enthält aber der Microcode für die Client CPUs (Ryzen etc.) dort nicht (oder nicht für alle) enthalten ist.
Scheinbar ist das auch so von AMD beabsichtigt und der offizielle / vorgesehene Weg ist es, dass Client CPUs nur über BIOS / UEFI Updates der Mainboardhersteller neuen Microcode erhalten.
Bei Intel ist das anders, da enthält “intel-ucode” auch den Microcode für die Client CPUs und der wird auch geladen, sofern der Microcode im BIOS / UEFI älter ist (kann man in “dmesg” sehen).
Hast du dafür eine Quelle?
In linux-firmware sind die folgenden microcodes enthalten:
microcode_amd.bin
microcode_amd_fam15h.bin
microcode_amd_fam16h.bin
microcode_amd_fam17h.bin
microcode_amd_fam19h.bin
Die processor families 17h und 19h decken alle ZEN CPUs ab. https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures
Hier ist ein Reddit Post, der auch weitere Links enthält.
Die Gentoo Wiki erwähnt es auch.
D.h. obwohl die Dateien wohl eine ganze CPU-Familie abdecken sollen, sind nicht alle CPU Modelle enthalten.
Am häufgisten sind davon wohl die Ryzen APUs / Laptop CPUs betroffen.
Und hier auch noch aus den Kommentaren von Phoronix.
Dann braucht man sich für einen AMD desktop ja überhaup keinen Kopf mehr zu machen über amd-ucode etc. Auch nicht schlecht.
Naja, wäre schön wenn AMD diese Praxis ändert. BIOS / UEFI Updates von den Mainboardherstellern kommen oft gar nicht oder spät und so ist man dann bei Sicherheitsproblemen der Dumme, obwohl AMD einen funktioniererenden Mechanismus hat, den Kram unter Linux zu verteilen. Es müssten halt nur alle Modelle dabei sein …
Wenn ich BS86 richtig verstanden habe, will man aber ja gerade dafür sorgen, dass es künftig in amd-ucode ist. Dann muss man ja doch wieder amd-ucode installieren. Finde das jetzt mit Dracut auch keine große Sache. Wird dann ja im Prinzip auch gleich eingespeist.
wenn du dracut nutzt, wird amd-ucode.img nicht verwendet.
Das wird nur verwendet wenn du es im Bootloader VOR dem initrd-Image preloadest - geht auch mit dracut ist aber unnötig. Nötig ist es nur, wenn du noch mkinitcpio verwendest (siehe Link in obigen Gitlab Task) Falls du mkinitcpio verwendest und trotzdem die Firmware-Files schon drin sind, solltest du das dringend in diesem Task posten, denn dann wollen die scheinbar was umsetzen was schon umgesetzt ist.
Dracut holt sich schon alles nötige aus /usr/lib/firmware
Die Info ist mir auch neu. Allerdings ist der Microcode für Consumer-CPU’s tatsächlich ja schon enthalten, er wird ihnen nur nicht korrekt zugewiesen - der Reddit Thread zeigt quasi wie man ihn nachträglich manuell richtig zuweißt xD
Ich benutze kein mkinitcpio. Nur dracut+systemd-boot.
Ich habe übrigens gerade ein BIOS update gemacht und das hat dann tatsächlich den microcode für meine AMD Ryzen 9 5900X angehoben.
Vorher:
microcode: CPU0: patch_level=0x0a201016
Jetzt:
microcode: CPU0: patch_level=0x0a20102b
Ist bei Zen4 auch leider immer noch so. Hatte das bei meinem 7700X letztes Jahr getestet.
Ich muss jetzt rein aus Interesse trotzdem nochmal blöd nachfragen: Könnte man dann überhaupt verhindern, dass Dracut dann den Microcode einspeist, wenn man (wieso auch immer) es nicht möchte?
So würde ich halt einfach das amd-ucode Paket entfernen und reinstall-kernels ausführen. Aber wenn das amd-ucode Paket gar nicht gebraucht wird - wie wird man den Microcode dann los? linux-firmware zu entfernen dürfte ein bisschen “overkill” sein. Wie gesagt - rein hypothetisch.
Edit okay… wenn ich das richtig verstanden habe könnte man für diesen fallle dracut mit –no-early-microcode nutzen
jep, oder nachdem Arch das Paket umstrukturiert hat, amd-ucode deinstallieren. Solange die Dateien in linux-firmware drin sind, geht es nicht weil linux-firmware eine harte Abhängigkeit des Kernel ist (ohne das Paket geht so gut wie gar nichts mehr, keine GPU, kein Netzwerk/WLAN etc)
Macht aber egal wie keinen Sinn, den Microcode zu entfernen, weil manche CPU’s bekommen ja ohne Anpassungen Updates daraus, und hoffentlich in Zukunft mal alle.
Edit 6 Tage später: Die Änderung des umziehens der AMD CPU firmware Dateien vom linux-firmware-Paket zu amd-ucode ist jetzt in testing. Die img Datei für mkinitcpio Systeme ist noch drin weil die Arbeiten an mkinitcpio noch nicht abgeschlossen sind.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.