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?
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
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.
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.
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.
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.
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...
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.
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]
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.
