"Intel CPU microcode updates" plugin questions/concerns

[Diggy]

I have some questions about the "Intel CPU microcode updates" plugin.

First, I'd like to say that it would have been nice if the pre-install description stated that the package is no longer being maintained.  It was only mention post-installation.

Second, I would consider this package to be very important with respect to security, so why is it not being maintained?  Further, why isn't it included as part of the core installation?

Third, I am using an HP server with the "Intel Xeon CPU E5-2620 v4" CPU.  How can I determine if my system will benefit from the microcode?

[nero355]

First, I'd like to say that it would have been nice if the pre-install description stated that the package is no longer being maintained.  It was only mention post-installation.

Second, I would consider this package to be very important with respect to security, so why is it not being maintained?  Further, why isn't it included as part of the core installation?

franco explained this a while ago so if you really want to know then look through his posts : https://forum.opnsense.org/index.php?action=profile;area=showposts;u=10

TL;DR : The message you have seen does not tell the whole story and can safely be ignored when using OPNsense :)

[meyergru]

1 & 2: The message does not apply to the microcode updates, you are misreading the console output.
3: Use "dmesg | fgrep microcode" on the CLI to see if an update was applied.

[Diggy]

3: Use "dmesg | fgrep microcode" on the CLI to see if an update was applied.

Apparently no microcode updates applied.  Output from that command:
[1] CPU microcode: no matching update found

[drosophila]

Will installing both intel and amd microcode plugins break anything? It's obviously not going to do any good on any given system, but it would be nice to know that migrating an installation to another platform wouldn't be prone to lack of microcode updates that might keep it from booting up. IOW, similar to having assorted drivers installed that aren't used.

[franco]

Well, you cannot install both plugins at the same time and it's also using loader.conf to select the microcode update using the same variable within FreeBSD:

% cat ./src/etc/rc.loader.d/40-cpu-microcode.in
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/%%PLUGIN_VARIANT%%-ucode.bin"

So even if you had both microcode packages installed and did the manual configuration you have to pick one and we're not going to add any glue that attempts to do that type of detection.


Cheers,
Franco

[drosophila]

OK, thanks for the clarification and concise info! Probably that scenario is rare anyway so it's reasonable to not code for it, especially since even stability fixes rarely would prevent a system from at least being able to install a plugin, contrary to a missing driver. I occasionally wondered why there are two separate ones instead of one combined microcode package, but maybe a clear distinction is better and saves a little space as bonus.

[Patrick M. Hausen]

In a stock FreeBSD you would install the "meta" microcode package which would install both vendor specific ones. Then you pick the one to load via rc.conf or loader.conf. You could of course activate both without ill effects apart from an error message by the "wrong" package at boot.

[drosophila]

I see, either way makes sense. It seems like I could implant the CPU type in the PLUGIN_VARIANT variable by deducing it from dmesg output, but that would probably be brittle, even if it can run early enough.

[BrandyWine]

cpu uCode should only need to be run once, when new uCode is available. Most times new uCode is for security reasons.

Having a system that always wants to install something on every boot, especially new uCode for cpu, does seem a bit dicey for my liking.

It would be better to have this feature as a manual check in the webgui, and if the user wants to the update can do uCode update and then system reboots.

[Patrick M. Hausen]

cpu uCode should only need to be run once, when new uCode is available. Most times new uCode is for security reasons.

A BIOS or OS microcode update will be lost after each power cycle and needs to be loaded at each boot - either by the BIOS (best) or by the operating system.

The OPNsense plugin provides an OS microcode update. No permanent changes to the CPU are done.

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html

[BrandyWine]

Sorry, my bad, Patrick is correct. uCode is lost during cpu boots.
It would however be better to have uCode in UEFI area, vs via OS.

That said, IIRC, in the past the plugin was constantly looking for uCode updates and would apply anything new. If my IIRC is correct than that feature should still be a manual check from GUI allowing end-user to decide when to allow new uCode to install.