# AMD CPU Microcode: not updating?

## danomac

I have this strange problem with my only AMD processor: it will not update the microcode. All of my Intel-based machines update no issues.

From spectre-meltdown-checker:

```

  * CPU microcode is the latest known available version:  NO  (latest version is 0x8701013 dated 2019/06/11 according to builtin firmwares DB v130.20191104+i20191027)

```

According to this, it should be version 0x8701013.

Dmesg:

```

# dmesg | grep -i micro

[    5.360524] microcode: CPU0: patch_level=0x08701011

[    5.360527] microcode: CPU1: patch_level=0x08701011

[    5.360529] microcode: CPU2: patch_level=0x08701011

[    5.360542] microcode: CPU3: patch_level=0x08701011

[    5.360549] microcode: CPU4: patch_level=0x08701011

[    5.360553] microcode: CPU5: patch_level=0x08701011

[    5.360558] microcode: CPU6: patch_level=0x08701011

[    5.360571] microcode: CPU7: patch_level=0x08701011

[    5.360586] microcode: CPU8: patch_level=0x08701011

[    5.360601] microcode: CPU9: patch_level=0x08701011

[    5.360614] microcode: CPU10: patch_level=0x08701011

[    5.360628] microcode: CPU11: patch_level=0x08701011

[    5.360644] microcode: CPU12: patch_level=0x08701011

[    5.360658] microcode: CPU13: patch_level=0x08701011

[    5.360672] microcode: CPU14: patch_level=0x08701011

[    5.360686] microcode: CPU15: patch_level=0x08701011

[    5.360689] microcode: CPU16: patch_level=0x08701011

[    5.360692] microcode: CPU17: patch_level=0x08701011

[    5.360697] microcode: CPU18: patch_level=0x08701011

[    5.360702] microcode: CPU19: patch_level=0x08701011

[    5.360706] microcode: CPU20: patch_level=0x08701011

[    5.360711] microcode: CPU21: patch_level=0x08701011

[    5.360716] microcode: CPU22: patch_level=0x08701011

[    5.360730] microcode: CPU23: patch_level=0x08701011

[    5.360745] microcode: CPU24: patch_level=0x08701011

[    5.360758] microcode: CPU25: patch_level=0x08701011

[    5.360772] microcode: CPU26: patch_level=0x08701011

[    5.360785] microcode: CPU27: patch_level=0x08701011

[    5.360799] microcode: CPU28: patch_level=0x08701011

[    5.360813] microcode: CPU29: patch_level=0x08701011

[    5.360827] microcode: CPU30: patch_level=0x08701011

[    5.360840] microcode: CPU31: patch_level=0x08701011

[    5.360843] microcode: Microcode Update Driver: v2.2.

```

The cpu only reports 0x8701011.

I have configured firmware updating in the kernel (note, I have graphics firmware and TV tuner firmware here too, they all load fine):

```

CONFIG_MICROCODE=y

# CONFIG_MICROCODE_INTEL is not set

CONFIG_MICROCODE_AMD=y

# CONFIG_MICROCODE_OLD_INTERFACE is not set

# Firmware loader

CONFIG_EXTRA_FIRMWARE="dvb-demod-si2168-b40-01.fw v4l-cx23885-avcore-01.fw nvidia/gp108/gr/fecs_bl.bin nvidia/gp108/gr/fecs_data.bin nvidia/gp108/gr/fecs_inst.bin nvidia/gp108/gr/fecs_sig.bin nvidia/gp108/gr/gpccs_bl.bin nvidia/gp108/gr/gpccs_data.bin nvidia/gp108/gr/gpccs_inst.bin nvidia/gp108/gr/gpccs_sig.bin nvidia/gp108/gr/sw_bundle_init.bin nvidia/gp108/gr/sw_ctx.bin nvidia/gp108/gr/sw_method_init.bin nvidia/gp108/gr/sw_nonctx.bin nvidia/gp108/acr/bl.bin nvidia/gp108/acr/ucode_load.bin nvidia/gp108/acr/ucode_unload.bin nvidia/gp108/acr/unload_bl.bin nvidia/gp108/nvdec/scrubber.bin nvidia/gp108/sec2/desc.bin nvidia/gp108/sec2/image.bin nvidia/gp108/sec2/sig.bin amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

```

I do not use an initrd and have no desire to use one. All the intel based machines do not use an initrd either and they work fine.

From what I can tell, it should be updating but it isn't with no indication as to why? Can someone shed light on this?

Edit: This is a Ryzen 3950x, it it possible it's so new it won't patch until AMD releases another update?

----------

## nvaert1986

 *danomac wrote:*   

> I have this strange problem with my only AMD processor: it will not update the microcode. All of my Intel-based machines update no issues.
> 
> From spectre-meltdown-checker:
> 
> ```
> ...

 

Usually CPU microcode comes with your manufacturers BIOS. So if your BIOS is recent, chances are that the microcode update will not be applied, because it's already current (or newer). The CPU microcode is only applied if it's newer than what is currently running.

----------

## NeddySeagoon

danomac,

Its possible that the latest firmware is not in your /lib/firmware.

----------

## krinn

https://cateee.net/lkddb/web-lkddb/EXTRA_FIRMWARE.html

tl:dr ?

It mean any firmware from EXTRA_FIRMWARE_DIR is build-in your kernel binary, and not read from the files when booting.

So any update firmware in EXTRA_FIRMWARE_DIR will never be read when booting as the firmware to use is buildin kernel : which mean to use a newer firmware, all you have to do is rebuilding your kernel ; but until you have rebuild it, the one in use will remain the one found when kernel was built.

If you wish a kernel without buildin firmware that read it from a file, use https://cateee.net/lkddb/web-lkddb/FW_LOADER.html

However do also note the comment specially in EXTRA_FIRMWARE_DIR help:

 *Quote:*   

> Built-in firmware searches are preceded over firmware lookups using your filesystem over the supported /lib/firmware paths documented on FW_LOADER.

 

which mean if a firmware is build-in a kernel, even you have tell it to use also loading firmware from file, the firmware used will always be the build-in one (no matter which one is newest)

----------

## saellaven

No issues here with my 3700x...

```

 dmesg | grep -i micro 

[    1.417550] microcode: CPU0: patch_level=0x08701013

```

```

Checking for vulnerabilities against specified kernel

CPU is AMD Ryzen 7 3700X 8-Core Processor

Kernel image is Linux version 5.4.12 (root@alpha) (gcc version 9.2.0 (Gentoo 9.2.0-r2 p3)) #1 SMP PREEMPT Thu Jan 16 04:25:05 EST 2020

  * CPU microcode is known to cause stability problems:  NO  (model 0x71 family 0x17 stepping 0x0 ucode 0x8701013 cpuid 0x870f10)

  * CPU microcode is the latest known available version:  YES  (latest version is 0x8701013 dated 2019/06/11 according to builtin MCExtractor DB v130 - 2019/11/04)

```

```

CONFIG_MICROCODE=y

# CONFIG_MICROCODE_INTEL is not set

CONFIG_MICROCODE_AMD=y

CONFIG_MICROCODE_OLD_INTERFACE=y

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

```

```

# equery l linux-firmware

 * Searching for linux-firmware ...

[IP-] [  ] sys-kernel/linux-firmware-20191215:0

```

Is your linux-firmware up to date? I suppose it's possible that the microcode update wasn't flagged for the 3950x the last time it was updated if so... I'd recommend trying a BIOS update in that case.

----------

## nvaert1986

- Also make sure the initramfs USE flag is set and that /boot is mounted (if it's a separate partition) when emerging linux-firmware

- Also make sure to run grub-mkconfig -o /boot/grub/grub.cfg after the linux-firmware package is done with emerging to add the initramfs with the AMD microcode to the boot process (with boot still mounted) with an initramfs  :Very Happy: 

----------

## danomac

Some more notes:

 -linux-firmware was updated yesterday.

 -I built a new kernel version (5.4.13) so the blobs in the kernel are up to date

 -I confirmed I actually booted the new kernel  :Wink: 

 -I don't use an initramfs (Intel's microcode updates without an initramfs)

 -The BIOS is the latest version

 -spectre-meltdown-checker indicates a newer firmware is available but it's not applying to my processor

I did check the dates under /lib/firmware and they are dated yesterday.

I know before the release of the 3950x (a week or two?) they updated the firmware blobs for Ryzen. But I don't know if they use a processor whitelist embedded in the blob itself.

----------

## saellaven

 *nvaert1986 wrote:*   

> - Also make sure the initramfs USE flag is set and that /boot is mounted (if it's a separate partition) when emerging linux-firmware
> 
> - Also make sure to run grub-mkconfig -o /boot/grub/grub.cfg after the linux-firmware package is done with emerging to add the initramfs with the AMD microcode to the boot process (with boot still mounted) with an initramfs 

 

initramfs/initrd are not needed unless your setup requires them

I'm using refind (UEFI booting) and don't have an initramfs/initrd (in part because the entire initramfs ideology creates a LESS robust system more prone to breaking)

----------

## saellaven

 *danomac wrote:*   

> Some more notes:
> 
>  -linux-firmware was updated yesterday.
> 
>  -I built a new kernel version (5.4.13) so the blobs in the kernel are up to date
> ...

 

I'm almost positive they would use a whitelist in the blob...

try manually loading the microcode with

```

echo 1 > /sys/devices/system/cpu/microcode/reload

```

----------

## nvaert1986

 *saellaven wrote:*   

>  *nvaert1986 wrote:*   - Also make sure the initramfs USE flag is set and that /boot is mounted (if it's a separate partition) when emerging linux-firmware
> 
> - Also make sure to run grub-mkconfig -o /boot/grub/grub.cfg after the linux-firmware package is done with emerging to add the initramfs with the AMD microcode to the boot process (with boot still mounted) with an initramfs  
> 
> initramfs/initrd are not needed unless your setup requires them
> ...

 

This actually is sort of required (unless you compile the firmware into the kernel)

The initramfs generates a amd-uc.img and places it into boot for you in the case of early microcode updating (the same is done with intel and intel-microcode). So it's technically an initramfs that gets loaded during boot. The alternative is to compile the individual microcode into the kernel..). When running grub-mkconfig -o it automatically detects this file and adds it as initramfs with the purpose of microcode updating.

The USE flag description for initramfs for linux-firmware is: "Create and install initramfs for early microcode loading in /boot (only AMD for now)".

----------

## The Main Man

 *saellaven wrote:*   

> 
> 
> ```
> 
> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin"
> ...

 

Just curious, why do you use amd_sev_fam17h_model0xh.sbin  ?

It's for server processors right ?

----------

## saellaven

 *nvaert1986 wrote:*   

>  *saellaven wrote:*    *nvaert1986 wrote:*   - Also make sure the initramfs USE flag is set and that /boot is mounted (if it's a separate partition) when emerging linux-firmware
> 
> - Also make sure to run grub-mkconfig -o /boot/grub/grub.cfg after the linux-firmware package is done with emerging to add the initramfs with the AMD microcode to the boot process (with boot still mounted) with an initramfs  
> 
> initramfs/initrd are not needed unless your setup requires them
> ...

 

ergo, it's not required... I DO compile the firmware into my kernel.

Again, initramfs makes your system LESS robust. There have been packages updated in the past which are not backwards compatible, leaving you unable to boot with your initramfs if you didn't rebuild it after updating said package (I want to say e2fsprogs or lvm2 was a critical one about 7 years ago, where the on-disk format had changed, leaving an old initramfs unable to boot an updated filesystem). If you're going to use an initramfs, you really should rebuild it every time you update your system just in case there's such an issue. That's fine for a binary distro where you're using their kernel, where it'll just push out an update for you, but in gentoo, you need to be more careful.

----------

## saellaven

 *kajzer wrote:*   

>  *saellaven wrote:*   
> 
> ```
> 
> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin"
> ...

 

It's for SEV (Secure Encrypted Virtualization). If you run a virtual machine, the memory is encrypted, reducing the ability of one guest being able to spy on the RAM that belongs to another guest. I'm not currently using it, but keeping the microcode updated doesn't hurt.

----------

## nvaert1986

 *saellaven wrote:*   

>  *nvaert1986 wrote:*    *saellaven wrote:*    *nvaert1986 wrote:*   - Also make sure the initramfs USE flag is set and that /boot is mounted (if it's a separate partition) when emerging linux-firmware
> 
> - Also make sure to run grub-mkconfig -o /boot/grub/grub.cfg after the linux-firmware package is done with emerging to add the initramfs with the AMD microcode to the boot process (with boot still mounted) with an initramfs  
> 
> initramfs/initrd are not needed unless your setup requires them
> ...

 

I actually do not recommend initramfs myself and do not use it myself, unless it's for microcode. The microcode initramfs files are so minimalistic  (mine's currently < 300KB) with almost nothing inside but firmware files, so it will keep things dynamic (not having to re-compile the kernel for new microcode) and this will not break things (unlike a full featured initramfs where I agree with you). It's also a separate initramfs file, from the main initramfs. There's a big difference there in my opinion.

----------

## saellaven

 *nvaert1986 wrote:*   

> 
> 
> I actually do not recommend initramfs myself and do not use it myself, unless it's for microcode. The microcode initramfs files are so minimalistic  (mine's currently < 300KB) with almost nothing inside but firmware files, so it will keep things dynamic (not having to re-compile the kernel for new microcode) and this will not break things (unlike a full featured initramfs where I agree with you). It's also a separate initramfs file, from the main initramfs. There's a big difference there in my opinion.

 

You can reload the microcode when a new version gets installed by linux-firmware without rebooting and I reboot every few days to install new kernels, so the initramfs option seems rather superfluous to me (does it matter if you recompile your kernel with new microcode or recompile your initramfs with new microcode?)

```

[    1.417550] microcode: CPU0: patch_level=0x08701013

[    1.418018] microcode: CPU1: patch_level=0x08701013

[    1.418473] microcode: CPU2: patch_level=0x08701013

[    1.418926] microcode: CPU3: patch_level=0x08701013

[    1.419375] microcode: CPU4: patch_level=0x08701013

[    1.419819] microcode: CPU5: patch_level=0x08701013

[    1.420252] microcode: CPU6: patch_level=0x08701013

[    1.420674] microcode: CPU7: patch_level=0x08701013

[    1.421080] microcode: CPU8: patch_level=0x08701013

[    1.421481] microcode: CPU9: patch_level=0x08701013

[    1.421874] microcode: CPU10: patch_level=0x08701013

[    1.422278] microcode: CPU11: patch_level=0x08701013

[    1.422661] microcode: CPU12: patch_level=0x08701013

[    1.423030] microcode: CPU13: patch_level=0x08701013

[    1.423387] microcode: CPU14: patch_level=0x08701013

[    1.423741] microcode: CPU15: patch_level=0x08701013

[    1.424098] microcode: Microcode Update Driver: v2.2.

```

microcode compiled into the kernel gets updated 1.4 seconds into boot. My ATA drives get recognized 1.8 seconds into boot and partitions get scanned 4.4 seconds into boot. If you're in an environment where you're concerned about security and early injection, those couple seconds may matter when using an initramfs.

I feel like this is getting overly pedantic. The simple fact is, an initramfs isn't necessary just to update microcode, so that's not danomac's problem... I suspect it's a whitelist issue with the firmware.

----------

## danomac

 *saellaven wrote:*   

> 
> 
> try manually loading the microcode with
> 
> ```
> ...

 

I've been busy, but I just tried this and it made no difference.

----------

## NeddySeagoon

danomac,

That command will load the microcode embedded in the kernel, rather than from /lib/firmware.

----------

## danomac

Ugh. I hate being busy.

That command

```

echo 1 > /sys/devices/system/cpu/microcode/reload

```

according to the wiki will look in /lib/firmware for the microcode. Thing is, on my system, dmesg doesn't report anything at all.

----------

## NeddySeagoon

saellaven,

Its possible to have several initrd files and use them all, so the microcode can be in its own initrd.

----------

## saellaven

 *NeddySeagoon wrote:*   

> saellaven,
> 
> Its possible to have several initrd files and use them all, so the microcode can be in its own initrd.

 

I find it saner to keep out the added complexity

----------

