Microcode check for Centos 7

[mphilipps]

hi,
Because microcode updates aren't part of systemd and therefore every distribution feels like they have to distribute them slightly different, they appear to be in /usr/share/microcode_ctl/ucode_with_caveats/intel/intel-ucode on Centos 7.
In #123 @duck-rh reported them to be in /lib/firmware/intel-ucode, but that directory does not appear to exist on Centos 6 or 7.

Given how much pain it is support every distribution on the planet, maybe we could just have a setting for the microcode path in needrestart.conf? That way package maintainer could set them to the correct value for their respective distribution.

[duck-rh]

@mphilipps this path is owned by the microcode_ctl package; AFAIU it is meant to hold the result of the iucode_tool and it is missing at first. The /usr/libexec/microcode_ctl/update_ucode script says « Maintain kernel-version-specific symlinks in /lib/firmware based on configuration present in /usr/share/microcode_ctl/ucode_with_caveats. ». I don't know when this script is called but it seems this is the proper path and the one you gave is used to prepare its content.

This path is also used in Debian in the intel-microcode package.

[mphilipps]

I am aware of the of the symlinks in /lib/firmware/$kernelversion, but checking against them seems like a just more convoluted way of checking against /usr/share/microcode_ctl/ucode_with_caveats/intel/intel-ucode.

You are right in that /lib/firmware/intel-ucode is owned by microcode_ctl, however I am not sure it still used. In /usr/libexec/microcode_ctl/update_ucode there is some code about creating symlinks there, but the script seems to be more concerned with deleting them.
Reading further there is some documentation in /usr/share/doc/microcode_ctl/README.caveats. From what I have gathered there /lib/firmware/intel-ucode might be used for manual late firmware updates. However afaik the recommended way of updating firmware is the early one through the initramfs. I didn't expect redhat to even support the 'whenever you feel like it' firmware update process.

Maybe it would be best to inspect the initramfs? lsinitrd shows a kernel/x86/microcode/GenuineIntel.bin in the early cpio image that should contain the microcode used after the next update.

[mphilipps]

lsinitrd -f kernel/x86/microcode/GenuineIntel.bin /boot/initramfs-3.10.0-957.12.2.el7.x86_64.img | iucode_tool -t b -l - looks promising,

[liske]

Adding a config options sounds reasonable so that advanced users are able to to configure the path on their own choice..