Please test early update of microcode for AMD CPUs using an amd-microcode package.
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Please test early update of microcode for AMD CPUs using an amd-microcode package.
Please find a package and instructions for testing in this repository. Top of the README below:
Quote:
This repository contains files needed to test the package amd-microcode on Slackware or derivatives.
The goal of testing is to check that after installation of this package and update of GRUB's /boot/grub/grub.cfg accordingly, at boot the microcode of AMD CPUs is updated early in the boot process.
Rationale:
Many (most) users do not keep their firmware up to date installing a new version when available, although these updates would alleviate security risks and functional issues.
But the Linux Microcode Loader allows to instead update the microcode, either integrating the updated files in it or applying them at each boot, through an initrd file.
It is preferable to use an initrd loaded early, to avoid having to rebuild a kernel every time new microcode files are available for either Intel or AMD.
The updated microcode files (presented in a CIPO archive as an intrd file) can then either integrated in a main initrd (like the one that can write mknitrd or dracut) or be in /boot, loaded early by the boot loader.
For Slint GRUB will load the microcode early and this is my recommendation for Slackware 15.1 as well. This way grub.cfg will need to be updated only once (after the microcode file has been included in /boot for the first time) as its name won't change after an update.
I request testing of this package and method here because I can't test myself by lack of a computer with an AMD CPU and as this feature could be included in Slackware without any modification.
I do not request testing this method for Intel CPUs (using an intel-microcode package for which a SlackBuild is available) as I have successfully tested it myself
@Didier , Hmm , AM I mistaken that there is no documented procedure to include the package in a initrd ?
As I do not use Grub '.' , I use elilo , So an initrd is all that is available to atm .
Tia , JimL
@Didier , Hmm , AM I mistaken that there is no documented procedure to include the package in a initrd ?
As I do not use Grub '.' , I use elilo , So an initrd is all that is available to atm .
Tia , JimL
What is considered "early loading" on AMD?
...
Are the "Speculative Return Stack Overflow:" lines indication of early loading? The "microcode:" lines show up much later in the boot process.
Early microcode loading should happen at (or very near) the beginning of the boot. In fact, on this here Intel (with microcode prepended to the initrd using mkinitrd's "-P" option,) the microcode loading for CPU0 is the very first line in the dmesg output:
Code:
dmesg | grep micro
[ 0.000000] microcode: CPU0 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.026070] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.002000] microcode: CPU1 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.002000] microcode: CPU2 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.002000] microcode: CPU3 microcode updated early to revision 0xbc, date = 2010-10-03
[ 1.024987] microcode: CPU0 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.027657] microcode: CPU1 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.033021] microcode: CPU2 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.035887] microcode: CPU3 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.038794] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Though I can't say for sure, I would suspect similar results for AMD. Perhaps Didier can confirm or disconfirm this suspicion...
Last edited by JayByrd; 09-10-2023 at 02:09 PM.
Reason: emphasis.
Early microcode loading should happen at (or very near) the beginning of the boot. In fact, on this here Intel (with microcode prepended to the initrd using mkinitrd's "-P" option,) the microcode loading for CPU0 is the very first line in the dmesg output:
Code:
dmesg | grep micro
[ 0.000000] microcode: CPU0 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.026070] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.002000] microcode: CPU1 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.002000] microcode: CPU2 microcode updated early to revision 0xbc, date = 2010-10-03
[ 0.002000] microcode: CPU3 microcode updated early to revision 0xbc, date = 2010-10-03
[ 1.024987] microcode: CPU0 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.027657] microcode: CPU1 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.033021] microcode: CPU2 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.035887] microcode: CPU3 sig=0x6fb, pf=0x4, revision=0xbc
[ 1.038794] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Though I can't say for sure, I would suspect similar results for AMD. Perhaps Didier can confirm or disconfirm this suspicion...
microcode: microcode updated early to new patch_level=0x0700010f
microcode: CPU0: patch_level=0x0700010f
microcode: CPU1: patch_level=0x0700010f
microcode: CPU2: patch_level=0x0700010f
microcode: CPU3: patch_level=0x0700010f
microcode: Microcode Update Driver: v2.2.
So it seems that you need to either get a firmware update from your machine's vendor or apply the early microcode update at each boot, as proposed in this thread.
Caveat: not all AMD CPUs can have their microcode updated this way, this depends of AMD releasing a blob to be included in /lib/firmware for your model.
Last edited by Didier Spaier; 09-11-2023 at 04:41 PM.
Reason: s/Ceveat/Caveat/
I request testing of this package and method here because I can't test myself by lack of a computer with an AMD CPU and as this feature could be included in Slackware without any modification.
Thanks for the attempt to include this in Slackware. Although kernel-firmware already brings it requiring some user steps to go, a dedicated package is much appreciated.
Test looks fine here:
Code:
$> sudo dmesg | grep microcode # from from kernel-firmware-20230906_ad03b85, before amd-microcode-20230907_dfa1146-noarch-1slint
[ 0.115445] Zenbleed: please update your microcode for the most optimal fix
[ 3.662325] microcode: CPU0: patch_level=0x08608103
[ 3.662350] microcode: CPU1: patch_level=0x08608103
[ 3.662388] microcode: CPU2: patch_level=0x08608103
[ 3.662422] microcode: CPU3: patch_level=0x08608103
[ 3.662469] microcode: CPU4: patch_level=0x08608103
[ 3.662490] microcode: CPU5: patch_level=0x08608103
[ 3.662528] microcode: CPU6: patch_level=0x08608103
[ 3.662565] microcode: CPU7: patch_level=0x08608103
[ 3.662597] microcode: CPU8: patch_level=0x08608103
[ 3.662620] microcode: CPU9: patch_level=0x08608103
[ 3.662642] microcode: CPU10: patch_level=0x08608103
[ 3.662665] microcode: CPU11: patch_level=0x08608103
[ 3.662689] microcode: CPU12: patch_level=0x08608103
[ 3.662708] microcode: CPU13: patch_level=0x08608103
[ 3.662729] microcode: CPU14: patch_level=0x08608103
[ 3.662741] microcode: CPU15: patch_level=0x08608103
[ 3.662751] microcode: Microcode Update Driver: v2.2.
$> gpg --import slackware.uk_slint_x86_64_slint-15.0_GPG-KEY.txt
$> gpg --verify amd-microcode-20230907_dfa1146-noarch-1slint.txz.asc
gpg: assuming signed data in 'amd-microcode-20230907_dfa1146-noarch-1slint.txz'
gpg: Signature made Thu Sep 7 14:44:12 2023 -03
gpg: using RSA key 0xD50202EF60C03EEA
gpg: Good signature from "Didier Spaier <didier@slint.fr>" [unknown]
$> sudo installpkg amd-microcode-20230907_dfa1146-noarch-1slint.txz
$> ls -la /lib/firmware/amd-ucode/microcode_amd_fam17h.bin /tmp/amd-ucode-arch.img /boot/amd-ucode.img
-rw-r--r-- 1 root root 12924 set 6 17:54 /lib/firmware/amd-ucode/microcode_amd_fam17h.bin # from kernel-firmware-20230906_ad03b85
-rwxr-xr-x 1 root root 81920 ago 9 17:33 /tmp/amd-ucode-arch.img* # from https://archlinux.org/packages/core/any/amd-ucode/
-rwxr-xr-x 1 root root 81920 set 7 11:18 /boot/amd-ucode.img* # from amd-microcode-20230907_dfa1146-noarch-1slint
$> sha256sum /lib/firmware/amd-ucode/microcode_amd_fam17h.bin /tmp/amd-ucode-arch.img /boot/amd-ucode.img
1eeaf4c86fb72a0f0e9d4ff28d3213d264ecb47a8dce8bcbd85addd0cfd999bb /lib/firmware/amd-ucode/microcode_amd_fam17h.bin
167698b918369c155a180015c6f5bd61a15a7be80f436f7762203a7a4cd88702 /tmp/amd-ucode-arch.img
60674fb6b0b1c9ab1a6623da59437acf9760d79bce4a936b1ea0cb7e34e6f2d2 /boot/amd-ucode.img
$> sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
...
Found linux image: /boot/vmlinuz-generic-6.1.52
Found initrd image: /boot/amd-ucode.img /boot/initrd-6.1.52.gz
...
done
$> reboot
$> sudo dmesg | grep microcode # with amd-microcode-20230907_dfa1146-noarch-1slint installed
[ 0.115682] Zenbleed: please update your microcode for the most optimal fix
[ 3.670132] microcode: CPU0: patch_level=0x08608103
[ 3.670168] microcode: CPU1: patch_level=0x08608103
[ 3.670219] microcode: CPU2: patch_level=0x08608103
[ 3.670255] microcode: CPU3: patch_level=0x08608103
[ 3.670287] microcode: CPU4: patch_level=0x08608103
[ 3.670322] microcode: CPU5: patch_level=0x08608103
[ 3.670347] microcode: CPU6: patch_level=0x08608103
[ 3.670367] microcode: CPU7: patch_level=0x08608103
[ 3.670388] microcode: CPU8: patch_level=0x08608103
[ 3.670417] microcode: CPU9: patch_level=0x08608103
[ 3.670437] microcode: CPU10: patch_level=0x08608103
[ 3.670483] microcode: CPU11: patch_level=0x08608103
[ 3.670526] microcode: CPU12: patch_level=0x08608103
[ 3.670554] microcode: CPU13: patch_level=0x08608103
[ 3.670582] microcode: CPU14: patch_level=0x08608103
[ 3.670619] microcode: CPU15: patch_level=0x08608103
[ 3.670646] microcode: Microcode Update Driver: v2.2.
$> sudo smc
Spectre and Meltdown mitigation detection tool v0.46
Checking for vulnerabilities on current system
Kernel is Linux 6.1.52 #1 SMP PREEMPT_DYNAMIC Wed Sep 6 18:36:07 CDT 2023 x86_64
CPU is AMD Ryzen 7 5700U with Radeon Graphics
...
* CPU microcode is known to fix Zenbleed: NO (required version: 0x08608105)
* CPU microcode is known to cause stability problems: NO (family 0x17 model 0x68 stepping 0x1 ucode 0x8608103 cpuid 0x860f81)
* CPU microcode is the latest known available version: NO (latest version is 0x8608104 dated 2022/03/28 according to builtin firmwares DB v273+i20230808+b6bd)
...
CVE-2023-20593 aka 'Zenbleed, cross-process information leak'
* Zenbleed mitigation is supported by kernel: YES (found zenbleed message in kernel image)
* Zenbleed kernel mitigation enabled and active: YES (FP_BACKUP_FIX bit set in DE_CFG)
* Zenbleed mitigation is supported by CPU microcode: NO
> STATUS: NOT VULNERABLE (Your kernel mitigates Zenbleed)
> SUMMARY: ...CVE-2023-20593:OK...
I have rebuilt the package just to include a few documents in it as indicated in the ChangeLog thanks to Debian and simplified its building thanks to Gentoo. Instructions for testing are now in README.testing.
Quote:
Originally Posted by denydias
Although kernel-firmware already brings it requiring some user steps to go, a dedicated package is much appreciated.
It is indeed possible for a user to trigger an early update of the AMD microcode at each boot several ways, like building /boot/amd-ucode.img with a small script, or just running dracut, that includes kernel/x86/microcode/AuthenticAMD.bin by default in the initrd it creates from the files provided by the kernel-firmware package. The idea is "less maintenance work" for the user .
It is indeed possible for a user to trigger an early update of the AMD microcode at each boot several ways, like building /boot/amd-ucode.img with a small script, or just running dracut, that includes kernel/x86/microcode/AuthenticAMD.bin by default in the initrd it creates from the files provided by the kernel-firmware package.
No need for anything but standard Slackware packages, namely kernel-firmware and libarchive. Just issue:
Code:
$> ls -1 /lib/firmware/amd-ucode/microcode_amd*
/lib/firmware/amd-ucode/microcode_amd.bin
/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
/lib/firmware/amd-ucode/microcode_amd_fam16h.bin
/lib/firmware/amd-ucode/microcode_amd_fam17h.bin
/lib/firmware/amd-ucode/microcode_amd_fam19h.bin
$> grep family /proc/cpuinfo | head -1
cpu family : 23 # 23 decimal is 17h (hexadecimal), so use it to match one of the files above in the commands bellow.
# Older 10h, 11h, 12h and 14h families, just use /lib/firmware/amd-ucode/microcode_amd.bin
$> echo /lib/firmware/amd-ucode/microcode_amd_fam17h.bin | \
bsdcpio -o -H newc -R 0:0 /lib/firmware/amd-ucode/microcode_amd_fam17h.bin > /boot/amd-ucode.img
Nicely done, no external utils required. More at Gentoo's wiki.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.