Ive been reading up abit on "intel microcode", and someone on this forum mentioned it in another x86 thread i saw, is this included in 19.07.3? Should i install it?
Both intel-microcode and amd64-microcode packages are available but not installed by default. You should install the correct one depending on your CPU vendor.
1 Like
So, for various reasons I kinda forgot about this microcode package.
Im trying to find out, why i need this? What if i dont have it?
Im using a Qotom Mini-PC with intel 6500u cpu
edit: im just careful to install stuff now since the router is working good for months
Yes, you do want to install it, to (at least partially-) mitigate against meltdown, spectre, et al.
3 Likes
So, for a bit more clarity, is installing the package pretty much the same as upgrading the BIOS, (for the microcode, assuming the BIOS upgrade has one) or different, or something in between? I'm guessing maybe both do the same thing for a microcode update?
What's the best way to see what the "version" is in the package, to compare with what might be in the most recent BIOS update?
Ideally, the mainboard manufacturers would update their BIOS-internal microcode packages in a timely fashion, but -in general- they don't. If they did, this OpenWrt package wouldn't be necessary, but the OS side packages are quicker/ easier/ safer to upgrade and often the only way to get recent microcode versions at all.
grep -i microcode /proc/cpuinfo will tell you the version, sadly there is no way (anymore - at least that I know of) to check the BIOS-side version of the microcode (without removing the OS-side package and comparing).
2 Likes
Hmmm... I was able to find this info for the package, https://openwrt.org/packages/pkgdata/intel-microcode and down the source link there's a changelog of sorts... But I'm having a hard time finding the version number from my box in the pile of numbers in the changelog. Is the version the "rev" or the "pf_mask"?
I've also found this, https://support.microsoft.com/en-us/topic/kb4497165-intel-microcode-updates-100229c5-e199-37bb-031f-9faa76daa07a where it seems there is a number for the latest, or at least when that article was written. (late 2020?)
So, with your command and another I found while reading, here's my processor:
root@Router:~# grep -i microcode /proc/cpuinfo
microcode : 0x2e
microcode : 0x2e
microcode : 0x2e
microcode : 0x2e
root@Router:~#
root@Router:~#
root@Router:~# grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u
cpu family : 6
microcode : 0x2e
model : 92
model name : Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
stepping : 9
I have 0x2e. From one of my above links they seem to mention a 0x38 (from the Intel Aug '19 guide?) or in a Microsoft one a 0x32, and even a 0x40 in a different doc?
Trying to map- and match that against individual CPUs is a full-time job - good luck.
The easier way would be to stop thinking, hoping the package maintainer hasn't overlooked anything and to merely try and compare version numbers.
Going to the manufacturer BIOS description, I know I did the update that deals with Spectre, (back in '18- '19?) but don't have the latest which fixes DMI issues and... some vauge stuff I can't quite tell from the description.
And, of course, they don't have the Intel rev number or anything that could be crossed over, just their own rev number.
Intel Apollolake (Celeron Processor), Passive Cooling, Mini PC Box
AMI BIOS
B325P012.BIN BIOS for Apollolake Celeron Processor, Passive Cooling
.64Mbit Flash size
.Initial mass production release
(April / 2017)
.64Mbit Flash size
.Removed built-in UEFI-Shell
.Changed CMOS Setup Boot Mode Option names to [ Legacy / Pure UEFI / UEFI Compatible ]
.Changed bootup function to show "No bootable device detected" when no bootable storage present during POST
(July / 2017)
.64Mbit Flash size
.Fixed "Power Button poor response" in Windows
(August / 2017)
.64Mbit Flash size
.Fixed "Hardware Error" message during Linux (Ubuntu) installation
(January / 2018)
.64Mbit Flash size
.Updated Intel CPU microcode patch for "Spectre" issue
(April / 2018)
.64Mbit Flash size
.Fixed DMI data loss during CMOS Clear
.Updated Intel CPU microcode for variant CPU
(April / 2020)
Ah well... Now, if I install the microcode package, is that a one way trip, or is it removable? I could do a bios bump (have to bring down the house net for a while though!) and then try the package, reading codes along the way. Or, just go there. Heh, then I'll regress myself when I install the possibly earlier BIOS? Wish this was easier to figure out ahead of time.
I'll try to come back and update, if/when I do the deed.
Edit: IIRC, I have done the 2018 BIOS update, not the 2020 one.
Interesting.. gives a load of info on the CPU, not including the microcode version though, and has status on the different vulnerablities (Spectre, etc) On mine, that part looks like this:
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
I went ahead and installed the intel-microcode package... and, nothing changes till a reboot.
Interestingly, before and after, in the syslog, you see the same, earlier version. Probably reading the BIOS microcode version?
[ 2.304473] microcode: sig=0x506c9, pf=0x1, revision=0x2e
[ 2.310093] microcode: Microcode Update Driver: v2.2.
Though, now, if you check the other way, you see it is updated:
root@Router:~# grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u
cpu family : 6
microcode : 0x38
model : 92
model name : Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
stepping : 9
And, after all that... if I do a lscpu again, I get exactly the same vulnerability results as before, assumably meaning that there's been no new fixes for those in the 0x38 code? Ah well. A long ride to find out I didn't change much. At least I had most of them done already. There's other changes in there I guess, just can't tell what!
I also tried the iucode_tool... that was fun, seemed to install but not work. Finally I noticed the package name is iucode-tool, but the actual tool name is iucode_tool! It seems pretty complex, not going to mess with it now just to read the contents of that microcode package.
1 Like
And, a couple days later, no issues. Hope all that helps someone else going down the path, in knowing things like the syslog won't reflect the package update, how to tell if you really are running the update and what it is.
And not to spend too much time chasing after revision info. 