Add devcpu-data plugin to provide CPU microcode updates

[tk-wfischer]

To protect against Spectre v2, IBRS requires microcode updates to the hardware (so that the CPU provides the "Structured Extended Features3" IBPB,STIBP) in order to be effective at all (see https://forum.opnsense.org/index.php?topic=7595.0) Protection against Spectre v4 needs further (even newer) microcode updates provides the "Structured Extended Features3" SSBD - see https://reviews.freebsd.org/rS334005 (I think this is not included in FreeBSD 11.2 anyway, I think this is FreeBSD 12.0 only)

Firewalls are often running remotely, so updating their BIOS to get a new CPU microcode is often hardly possible. Furthermore many systems do not get updated BIOS images from their vendors - so the only left way to update the microcode is the operating system.

I suggest to add the package "devcpu-data" by default to OPNsense. In addition the following entry should be added to /etc/rc.conf so that microcode updates are applied on boot:

microcode_update_enable="YES"

Once OPNsense switches to FreeBSD 12.0, the following lines should be added to /boot/loader.conf (in this way the microcode update is applied sooner during boot):

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

Further information regarding updating microcodes can be found in this (German) wiki article: https://www.thomas-krenn.com/de/wiki/Intel_Microcode_unter_FreeBSD_aktualisieren (edit: now also in English: https://www.thomas-krenn.com/en/wiki/Update_Intel_Microcode_on_FreeBSD)

[fichtner]

I'm in favour of having plugin without a GUI similar to what os-boot-delay does, but not for making this a core dependency or default install plugin (like os-dyndns). Microcode is only fixed on each bootup and there could be glitches in bootup due to patching the live processor although I haven't heard that happening yet.

[tk-wfischer]

Thanks for your valuable feedback. I have not thought about the possibility to include this via a plugin. In order to keep the core footprint small it a good idea to use a plugin to implement this. Should I close this issue here and open a new one at https://github.com/opnsense/plugins/issues?

[fichtner]

We can do this via GitHub now. Okay, let's do this... I'll build the plugin after 19.1 release process is done.

[mr44er]

Some experience sharing:

As correctly stated from tk-wfischer it should be loaded in earliest state possible (/boot/loader.conf) to minimize the time span the system stays unprotected. This method needs FreeBSD 12.

I used sysutils/devcpu-data already on FreeBSD 11.2, so the waiting for 12 isn't technically necessary (last sentence). I tested this: had both methods parallel enabled. Checked on AMD and Intel, on FBSD11.2/12 and vice-versa. It is safe and works.

Installing this port will allow host startup to update the CPU microcode on
a FreeBSD system automatically. There are two methods for updating CPU
microcode: the first methods loads and applies the update before the kernel
begins booting, and the second method loads and applies updates using an
rc script. The first method is preferred, but is currently only supported
on Intel i386 and amd64 processors running FreeBSD 12.0. It is safe to
enable both methods.

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
The intel-ucode.bin could be irritating for AMD-users. There is no amd-ucode.bin, so intel-ucode.bin is always correct, it includes the microcode for both - Intel and AMD

There exists another tool for microcode updates:
https://www.freshports.org/sysutils/cpupdate/
https://github.com/kernschmelze/cpupdate
I haven't tried it yet, can't say something about pros/cons, but the author says it should be compiled (to work properly, but have no idea what's the reason), which could be a problem to integrate in opnsense.

[tk-wfischer]

Thanks for your input. In the meantime I did some further testing and documented the Microcode update via both devcpu-data and via cpupdate.

You can find the article here: https://www.thomas-krenn.com/en/wiki/Update_Intel_Microcode_on_FreeBSD

[soder10]

Some experience sharing:

As correctly stated from tk-wfischer it should be loaded in earliest state possible (/boot/loader.conf) to minimize the time span the system stays unprotected. This method needs FreeBSD 12.

I used sysutils/devcpu-data already on FreeBSD 11.2, so the waiting for 12 isn't technically necessary (last sentence). I tested this: had both methods parallel enabled. Checked on AMD and Intel, on FBSD11.2/12 and vice-versa. It is safe and works.

Installing this port will allow host startup to update the CPU microcode on
a FreeBSD system automatically. There are two methods for updating CPU
microcode: the first methods loads and applies the update before the kernel
begins booting, and the second method loads and applies updates using an
rc script. The first method is preferred, but is currently only supported
on Intel i386 and amd64 processors running FreeBSD 12.0. It is safe to
enable both methods.

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
The intel-ucode.bin could be irritating for AMD-users. There is no amd-ucode.bin, so intel-ucode.bin is always correct, it includes the microcode for both - Intel and AMD

There exists another tool for microcode updates:
https://www.freshports.org/sysutils/cpupdate/
https://github.com/kernschmelze/cpupdate
I haven't tried it yet, can't say something about pros/cons, but the author says it should be compiled (to work properly, but have no idea what's the reason), which could be a problem to integrate in opnsense.

Sorry, but you are contradicting to yourself:
Freebsd12 is needed for the best possible solution called as Method#1 (apply update via loader.conf as early in the boot process as possible). Then you say: I have applied both Method#1 and Method#2 under Freebsd 11.2.
As opnsense is based on freebsd 11.2, Method#1 should have 0 effect, and only Method#2 is supposed to work. Or did I mix things completely up??

For Method#2 under opnsense19.1/freebsd 11.2:
do I need to manually enable "cpuctl" kernel module as a prerequisite? As by default cpuctl.ko is NOT loaded under freebsd 11.2 (have no clue if its auto-loaded under 12.0), and nobody dared to mention this tiny little detail as a showstopper sofar.

How do you load arbitrary kernel modules in opnsense custom-bsd, if the loader.conf change you made by hand-editing it is ovewritten at the very next time you apply changes via the GUI?

And last but not least: Method#2 requires you to edit the /etc/rc.conf file, which simply does not exist under the opnsense-customBSD. So the guide above is not really useful for non-stock freebsd OS, like opnsense.

[mr44er]

Or did I mix things completely up??

No, you did not. Maybe I did not state it clearly enough.
To rule out the suggestion, that devcpu-data only works for FBSD 12 and upward I said, that it can be used on 11.2. But with limitation to rc.conf (later load) and not with loader.conf (earliest load).

As opnsense is based on freebsd 11.2, Method#1 should have 0 effect, and only Method#2 is supposed to work.

Because of this I said, it doesn't hurt (safe use) to have this entry 1x in rc.conf and 1x in loader.conf at the same time.

And last but not least: Method#2 requires you to edit the /etc/rc.conf file, which simply does not exist under the opnsense-customBSD. So the guide above is not really useful for non-stock freebsd OS, like opnsense.

I don't know. Because of all this I had in mind, that devcpu-data maybe gets built-in before opnsense's update to FBSD 12.

[soder10]

Just wanted to give headsup to anyone who has tried this on 20.7, as that is already running FBSD 12.1 now.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.