X86 kernel MICROCODE_OLD_INTERFACE configuration

In the description in kenrel_menuconfig they strongly discourage using MICROCODE_OLD_INTERFACE saying:

DO NOT USE THIS! This is the ancient /dev/cpu/microcode interface
which was used by userspace tools like iucode_tool and microcode.ctl.
It is inadequate because it runs too late to be able to properly
load microcode on a machine and it needs special tools. Instead, you
should've switched to the early loading method with the initrd or
builtin microcode by now: Documentation/x86/microcode.rst

It is selected "yes" by default. Does Openwrt still need this? (I presume yes since it is selected).
If so, is it anything for me to be concerned about?

1 Like

Maybe? Maybe not? What devices you have, what software you run on these devices?

Microcode packages are not installed by default in x86 target, so by default nothing is loaded.

Microcode packages are relevant ONLY for people running OpenWrt on devices of x86 target, which means devices with Intel and AMD processors (PCs big or small).

If you need to run the latest microcode you can install the packages, and then microcode for AMD and Intel is loaded with the "early loading" method since 2018

Afaik that compile option is required to use iucode-tool inside OpenWrt to reload microcode after boot. Most devices don't need this.

maybe the peson that added most of this infrastructure can answer better
@wigyori

1 Like

I am building for an Intel x86 (look below for /proc/cpuinfo) . After testing, it will eventually be a router/firewall in a business production environment so I am just trying to get all the performance out of it I can, which should normally be no problem for an x86-64; however, it will be moving quite a lot of data via a 4 port 10GB PCIe card, with SQM, an OpenVPN server, a wireguard server, and multiple WAN connections.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 158
model name	: Intel(R) Pentium(R) Gold G5400 CPU @ 3.70GHz
stepping	: 10
microcode	: 0x9a
cpu MHz		: 3606.198
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips	: 7392.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

I realize that OpenWRT is mainly designed for embedded systems, but have always liked it for x86 network infrastructure systems over a regular Linux distro because of the performance, purpose-built design with no unneeded features, and Luci GUI config interface (especially for other SysAdmins that may not be as familiar with Linux it really helps). Plus I am familiar with it as I have used it for many embedded personal projects over the years starting around the days of Attitude Adjustment.

Also, thanks for the commit links.

As you see in the bugs list in your cpuinfo, that CPU (like a lot of Intel CPUs, even very new ones) has a bunch of security bugs you can google in your own time because it's a lot of reading.

Disclaimer: I'm NOT a security expert and this is NOT professional advice. I'm just a dude on a forum that has a "super-IT" image as avatar.

the tl;dr (which is still a sizeable amount of text) is that there are microcode updates that mitigate many of those but they can have a significant performance impact on CPU. How much depends from usecase (what applications you run). Most of these vulnerabilities are a problem only/mostly for systems running untrusted code (like a PC running applications installed from the internet or a server running virtual machines using KVM Linux hypervisor), and this is not what a router is going to do. You will install a few applications from trusted sources (OpenWrt package repositories) and that's it.

Since "microcode updates" are not a permanent thing, every time you reboot they must be "installed" again, which is why these packages exist. Microcode is not like BIOS, you do not install it once and then it is saved permanently in a chip.
Technically speaking, microcode can be included in BIOS updates too, and BIOS can install microcode updates too, but BIOS never get updated past a few years that the motherboard is released so they lag behind.

You can start with including the package with the microcode for Intel, and see if the performance is enough for what you need. If that is enough you leave it. If you see you have performance issues try uninstalling that package, powering off, pulling the power cord, press power button for 20 seconds (to be sure any capacitor in the PSU is discharged and no component on the board is receiving power anymore, so you can be sure any microcode you loaded before is forgotten), then connect power plug again and power on.

As for your original question about MICROCODE_OLD_INTERFACE:
this interface allows an application running as root to update the microcode without rebooting the system. This is technically a security problem because it would allow an application to "update" the microcode with a vulnerable one so it can exploit the abovementioned vulnerabilities again.

And of course it is also a security problem if you don't install microcode updates as early as possible because again an application could manage to run before the microcode update and exploit the vulnerabilities. But this does not happen in OpenWrt as I said above

microcode updates are signed by Intel and you cannot just load whatever you want, the CPU will reject it. So "application running as root loading old microcode with a vulnerability" is the extent of the problem.

If a malicious application is running as root on your router, you have bigger problems than microcode updates, so I'd say eh.

Usage of OpenWrt on x86 has been on the rise for a while, both bare metal and in containers or VMs.
A month ago someone from a VPN provider sent a commit to raise the max CPU core count from 8 to 512, because servers https://github.com/openwrt/openwrt/commit/df554e6fcab171ec499d8fb2ed10a0da328323f3
It's not in next release though, so that is still limited to 8 CPU cores max

Unrelated to the question, but may be important for you too. Can you tell me what brand/model that is? I wouldn't mind getting one of those myself if it does not cost an arm and a leg.

Also did you try it on OpenWrt or Linux already?

Maybe you should consider looking for another solution such as pfSense or OPNsense (I'm not trolling).

this forum is full of damn traitors it seems :rofl:

Why you say that, OpenWrt on x86 is just as good as those, and can run on much more hardware. For example I'm not sure pfSense or OPNSense even support the 10Gbit card he uses, they are very picky about network chipsets.

1 Like

Well like I said, I am most familiar with Openwrt configuration setup and I have found the GUI to be relevantly easy as far as training other SysAdmins. Also, ( I am not as familiar with pfsense so I may be inaccurate) pfsense does not have as many options when compared to the software packages available as Openwrt. I actually already have a working system running Openwrt with all the above features that has been running great for three years now. It is very fast. The reason I am building a new operating system for it is our insurance has a requirement that all network infrastructure must use some form of multi factor authentication. I am working on a way to implement this that will not lock me out in the event of a complete network outage. I have a few ideas in mind, but I figured while I was building a whole new image I would do any other optimizations I could, hence my reason for this post. For instance, I could be wrong, but I do not believe that pre-built Openwrt images come with AES-NI instruction sets, accelerated, OpenSSL libraries, and whatnot. I also like to replace dropbear with OpenSSH, and make a BASH shell the default, BIND DNS running backup for our AD server among many other things. Finally, I like to build with our config files already inserted so a pre-made archive image can be bare metal restored quickly in the event that I am not here and another SysAdmin has to replace a hard drive or something. I do know that pfsense is geared more towards the business environment similar to this use application and I know they are known for being good as far as security but it is mainly a personal preference and my familiarity with the Openwrt ecosystem. If I were a contractor or reseller selecting a product that I would not be in charge of administering than perhaps I would consider pfsense. In this case however, I work for the company (about 200 employees) and am in charge of Network/Systems design, engineering, administration, etc... so this is a system that I will be staying close to as long as I am employeed here.

Unrelated to the question, but may be important for you too. Can you tell me what brand/model that is? I wouldn't mind getting one of those myself if it does not cost an arm and a leg.

Also did you try it on OpenWrt or Linux already?

Yes, I hinted at it in the reply to badulesia but I am currently running it in Openwrt. It is a 4x SFP port Intel XL710. A link to it is below...

Amazon Link

At the time, I had to enable a kernel config option to get the SFP ports working correctly with fiber (somehow the RJ45 1 gigabit ones worked without it). I think it was in addition to the normal Intel 10GB kmod package in the openwrt build config but I cannot remember. I can look at my notes later if you would like to know specifically which one.

1 Like

So to follow up with my last reply to your question, I believe that at the time I compiled it it required the SFP kernel config option to be set. I actually was looking for it again earlier as I assumed I would need it again but no matter what I do I can not get it to appear in kernel_menuconfig. Maybe I should of started a new question for this but here is where it is...

Symbol: SFP [=n]                                                                                                                                                  │  
  │ Type  : tristate                                                                                                                                                  │  
  │ Prompt: SFP cage support                                                                                                                                          │  
  │   Location:                                                                                                                                                       │  
  │     -> Device Drivers                                                                                                                                             │  
  │       -> Network device support (NETDEVICES [=y])                                                                                                                 │  
  │ (1)     -> PHY Device support and infrastructure (PHYLIB [=y])                                                                                                    │  
  │   Defined at drivers/net/phy/Kconfig:334                                                                                                                          │  
  │   Depends on: NETDEVICES [=y] && PHYLIB [=y] && I2C [=y] && PHYLINK [=n] && (HWMON [=y] || HWMON [=y]=n)                                                          │  
  │   Selects: MDIO_I2C [=n]         
1 Like

I'll never turn to the dark side !
I'm running OpenWrt on a x64 as main router. It is more user-friendly than "the others I can't name".

1 Like

100% agreed. I had a look to "the others" for technical purpose. They are very powerfull in options, but difficult to handle. OpenWrt is much more user-friendly.

So to follow up with my last reply to your question, I believe that at the time I compiled it it required the SFP kernel config option to be set. I actually was looking for it again earlier as I assumed I would need it again but no matter what I do I can not get it to appear in kernel_menuconfig. Maybe I should of started a new question for this but here is where it is...

Nevermind, disregard this. I found it in the regular menuconfig as a kmod instead of the actual kernel menuconfig. I am not even sure I need it for a PCIe SFP board anyways.

1 Like