|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
I just received an Intel Microcode update in the Update Manager of my Linux Mint 19.1. I’m seeing good things said about these coming from comments on the Windows Updates, so I’m assuming it’s safe to install the one I got on my 2007 Sony VAIO with an Intel Core Duo CPU?
One of the reasons I switched to Linux as my primary OS/daily driver is the experience I had with Ubuntu 16.04 LTS and then later with 18.04 LTS, both on a circa 2009 HP laptop. As a test to see how easy it was to keep updated I installed EVERY update offered to me since August of 2016. Not a single problem (and at about 5 to 10 patches per week for four plus years, that’s a lot of patches). Among those patches have been a fair number of Intel microcode updates, especially back in 2017 (I think) when there was the huge scare about a couple Intel flaws that were going to doom the universe. I don’t remember the names of the flaws but it made international news. I never noticed any kind of performance hit on the HP laptop for any patch – microcode or not.
In the last year or so I’ve had Mint 19.2 Cinnamon running on an old Gateway netbook, an old Acer laptop and a relatively new (2016) Dell Inspiron (my daily driver). I’ve kept them all patched with every offered update, including a couple microcode patches, and never detected any kind of performance hit (or any other issue).
I got the same microcode update you did and plan to install it and all the other week’s patches tomorrow or Friday. Personally, I have no qualms about it, but if you want to wait, I’ll let you know how it turns out for me.
I don’t think it will make any difference. The Core 2 Duo is old enough that Intel dropped plans to release Spectre/Meltdown updates back when they hit, and they probably still have not. I can check for you, though… just enter
dmesg | grep microcode
into the terminal, and if you tell me what it says for ‘sig=0x??????’, I can see if it is in the list of included microcodes. The intel-microcode package is pushed to all Intel CPUs, even if there is no updated microcode inside.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
Indeed, that is the newest microcode listed for your CPU, way back from 2010. This line describes your CPU (this is from the intel-microcode package log), and is the version provided:
sig 0x000006fd, pf mask 0x80, 2010-10-02, rev 0x00a4, size 4096
That matches what you reported exactly.
So you’re vulnerable to the exploits that require a microcode update, but you’re immune to the performance losses they may cause. I have a computer from that era (2008 manufacturing date) when Spectre and Meltdown landed, and at first, Intel was planning to release microcodes for Core 2, but they changed their mind and didn’t. I didn’t worry about it much when I was using that PC as one of my main set (I use more than one each day). I since bought my Swift, which took over the role of the Core 2 Duo laptop (about the same performance, but much lighter and several times longer battery life).
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
FWIW, I installed all the Mint 19.2 Cinnamon updates offered (12 for me) on my guinnea pig Gateway netbook with an Atom Intel processor. I didn’t check whether it needed the microcode, but it installed without issue and I can’t tell any difference in performance. All 11 other updates went in just fine as well.
I’ve got 2 more machines to update, probably tonight or tomorrow.
You can install the microcode updates. When you boot Linux, the boot loader queries the CPU for its CPUID. If a newer microcode matching the CPUID is found, it is loaded into the CPU at boot time. If no new microcode for the CPUID is found, then nothing happens.
Windows 10 does the exact same thing as Linux. I can’t remember if Microsoft did the same thing for Windows 8. Microsoft decided not to do this for Windows 7. The only thing which Windows 7 got was Meltdown protection. No Spectre protection for Windows 7.
? says:
thank you, Ascaris. this mitigation shenanigans that started a few years ago was yet another reason i shifted my computing from intel\windows toward amd\linux. i tried the “dmesg | grep microcode,” but that only seems to work on an intel processor (comes up blank.)
“grep -F -m 1 “cpu family” /proc/cpuinfo,” told me about the amd family 15, (cpu family : 15) which is too long-in-the-tooth for the mitigations, and
“dmesg | grep -e ‘microcode’ -e ‘Linux version’ -e ‘Command line,’ gives: “([ 0.000000] Linux version 4.4.0-194-generic (buildd@lcy01-amd64-015) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12) ) #226-Ubuntu SMP Wed Oct 21 10:20:20 UTC 2020 (Ubuntu 4.4.0-194.226-generic 4.4.236),” which means i dunno…
? says:
hi Charlie,
this acer from the same era had 1 bios update offered shortly after it came into being and no microcode updates available that i’m aware of. ubuntu has pushed out several amd and intel patches over the last few years which are installed. when booting this machine i get the “LFENCE not serializing, switching to generic retpoline,” line in the syslog. i found a linux mint blog that may help:
? says:
just to kick the can all the way down the street from the mint blog i refered to above which explains Ascaris’ post #2311564 above in greater detail i ran terminal cmd “grep . /sys/devices/system/cpu/vulnerabilities/*,” and all the others to verify and got this result:
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: kernel-off, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/srbds:Not affected
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
so in summation, please don’t worry-be happy!
? says:
charlie, i don’t like the vulnerable part(s). i remember reading something about AMD not being as wide open as intel back when the story came out. maybe that is why your report differs on the KVM, mds, and specc_store_bypass? at any rate i don’t know if these vulnerabilities are actively being exploited and wrecking havoc. another reason i run linux live and usb sticks. wash rinse repeat and keep anything worth keeping in a safe place…
I remember a lot of talk back when Spector & Meltdown were a big thing scaring everyone. I remember it being said that it took a lot of time and effort for a hacker to use them. Hacking into a CPU seems like a waist of time unless there’s something of great value on that particular computer. Think I’ll just stay being happy. 
I remember it being said that it took a lot of time and effort for a hacker to use them. Hacking into a CPU seems like a waist of time unless there’s something of great value on that particular computer. Think I’ll just stay being happy.
I agree. It seems that the threat of random, drive-by exploitation of this by a rogue script on a compromised site is minimal, with the main risk being specific computers targeted by someone for the info therein.
The hoopla may have served a purpose, though, if it resulted in so many people getting the updates (or being perceived as getting them) that the baddies think it’s not worth their time to write malware that uses the side-channel attack method, or to give up on it sooner if it does not work at first. It’s not as if this is the only tool in the box, from their perspective.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
This is my interpretation:
If you download a firmware update from the MB mfg, and you flash the BIOS, it will affect anything that uses the BIOS (ie Mint and Win7). You are making changes to something used by both systems .
If you download microcode from Linux (do not flash the BIOS) it is applied by the Linux OS and shouldn’t affect the Win7 OS. If you download the microcode from MS (do not flash the BIOS), it is applied by the Win OS and shouldn’t affect the Linux OS.
? says:
you are correct (again) PK. volatile vs non-.
https://www.askwoody.com/forums/topic/dual-boot-linux-to-update-bios-on-win-7-pc/
and
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Notifications
