[PVE 9.2 Fresh Install] Intel-Microcode kernel module disabled by default?

[SInisterPisces]

Ref: https://pve.proxmox.com/wiki/Firmware_Updates#sysadmin_firmware_cpu
PVE Versions:

• proxmox-ve: 9.2.0 (running kernel: 7.0.14-11-pve)
• pve-manager: 9.2.4 (running version: 9.2.4/5e5ae681198514d4)

I just installed PVE with the latest ISO. I'm switched over to the enterprise repos.
I dropped into the /etc/modprobe.d subdirectory to tweak the ZFS ARC size caps, and noticed there's a new default blacklist for intel-microcode.

root@pisces1:~# cat /etc/modprobe.d/intel-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.

blacklist microcode

I don't see anything in the wiki about this. What's it talking about?

1. The intel-microcode package is installed by default and seems to be active (see output below).
2. There is no "microcode" module visible with lsmod.

I haven't touched anything yet, because I don't really understand what "unsafe" means in this context.

Meanwhile, the intel-microcode package from apt seems to be installed and working?

root@pisces1:~# apt info intel-microcode
Package: intel-microcode
Version: 3.20251111.1~deb13u1
Priority: standard
Section: non-free-firmware/admin
Maintainer: Henrique de Moraes Holschuh <hmh@debian.org>
Installed-Size: 21.4 MB
Depends: iucode-tool (>= 1.0)
Recommends: initramfs-tools (>= 0.113~)
Conflicts: microcode.ctl (<< 0.18~0)
Homepage: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
Download-Size: 12.8 MB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages
Description: Processor microcode firmware for Intel CPUs

Notice: There is 1 additional record. Please use the '-a' switch to see it
root@pisces1:~# grep microcode /proc/cpuinfo | uniq
microcode       : 0xf6
root@pisces1:~# dmesg | grep microcode
[    0.622898] microcode: Current revision: 0x000000f6
[    0.622909] microcode: Updated early from: 0x000000f4

I think I'm okay here? Or do I need to unblacklist the kernel module?

If I do, I think the wiki needs to be updated. Is the best way to do that to put in a bug report?

 

[leesteken]

I just installed PVE 9.2 in a VM (x86-64-v3) to make sure, but also double checked other Debian templates and VMs. I don't see that file. I do see an file with the same contents but it is named /etc/modprobe.d/amd64-microcode-blacklist.conf. Is this filename a harmless LLM mistake? This relic is not specific to Proxmox; maybe talk to Debian about this? I think it is not currently related to Intel or AMD microcode and rather harmless.

 

[SInisterPisces]

I just installed PVE 9.2 in a VM (x86-64-v3) to make sure, but also double checked other Debian templates and VMs. I don't see that file. I do see an file with the same contents but it is named /etc/modprobe.d/amd64-microcode-blacklist.conf. Is this filename a harmless LLM mistake? This relic is not specific to Proxmox; maybe talk to Debian about this? I think it is not currently related to Intel or AMD microcode and rather harmless.

Thanks for checking this on your machine.

I don't know what a "harmless LLM mistake" is, since I didn't use an LLM to install PVE or write my post about this.

I suspect the difference in filename is because you're on an AMD system, and I'm on an Intel system, though I'm not sure how it detects that inside a VM if you're not using the host VM type. Just another incident wherein I learn how little I understand about how PVE works.

It definitely sounds like a Debian thing. I'll ask over on their subreddit and report back if I get a useful response.
But yeah, sounds like it's something Debian keeps off by default.
https://wiki.archlinux.org/title/Microcode

Loading microcode​

Microcode updates are usually shipped with the motherboard's firmware and applied during firmware initialization. Since OEMs might not release firmware updates in a timely fashion and old systems do not get new firmware updates at all, the ability to apply CPU microcode updates during boot was added to the Linux kernel. The Linux microcode loader supports three loading methods:

1. Built-in microcode can be compiled into the kernel and then applied by the early loader.
2. Early loading updates the microcode very early during boot, before the initramfs stage, and is preferred over late loading. This is mandatory for CPUs with severe hardware bugs, like the Intel Haswell and Broadwell processor families.
3. Late loading (which may be dangerous) updates the microcode after booting which could be too late since the CPU might have already tried to use a faulty instruction. Even if already using early loading, late loading can still be used to apply a newer microcode update without needing to reboot.

Given the similarity in language (e.g., "dangerous"), I'm guessing the blacklist entry disables late loading, but I haven't confirmed that.

Late loading​

Warning Late microcode loading is considered dangerous, using it will taint the kernel.

Late loading of microcode updates happens after the system has booted. It uses files in /usr/lib/firmware/amd-ucode/ and /usr/lib/firmware/intel-ucode/. The microcode update files are provided by amd-ucode and intel-ucode, respectively.

Late loading requires the kernel to be built with CONFIG_MICROCODE_LATE_LOADING=y, which is not the case for Arch officially supported kernels at the moment. [1]

That sounds very much like the kernel module that's being blacklisted here.