When I used Ubuntu 16.04, intel-microcode was available in the additional drivers tab. But it’s no longer showing up on Ubuntu MATE 18.04. I ran apt-cache policy intel-microcode and found that I don’t have the it installed. Moreover, I get the following with a dmesg command:
sudo dmesg | grep --color -i "microcode"
[sudo] password for sakib:
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
[ 0.803747] microcode: sig=0x306c3, pf=0x2, revision=0x19
[ 0.803800] microcode: Microcode Update Driver: v2.2.
I’m a little worried because of the recent spectre-meltdown vulnerability. I googled a bit and researched here and there and it seems like this option has been deliberately removed, which I think makes my system vulnerable…
So, should I keep my system as it is or install intel-microcode manually?
I’d just install the intel-microcode package manually.
Btw. that TSC_DEADLINE message isn’t related to the recent vulnerabilities.
Edit #2: the contents of the files in /sys/devices/system/cpu/vulnerabilities/ indicates both kernel-side mitigations and microcode-dependent ones after all, but is a bit confusing to decipher.
It’s easiest to use this script instead as it is much more verbose:
https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
So here’s the deal, one way finding vulnerabilities is to check the directory as you said. Before installing microcode the output showed no such vulnerabilities.
After installing the microcode, the same command is now showing me a vulnerability( the TSC_DEADLINE message is gone though). Moreover, the kernel didn’t load the latest microcode, which I installed.
The microcode not detected on the additional drivers tab is pretty much hinted here.
And also the bash script that you’ve provided link to has given very much the same output before and after installing.
I’m confused as hell now. Any experts might want to help? @Bill_MI
Which CPU do you have?
Unfortunately Intel does not offer Spectre Microcode updates for all of their CPUs. I have a Wolfdale Core2Due here, for example, that won’t get updated, according to Intel.
Also, can you post the output of the script?
1 Like
Kernel is Linux 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES (Intel STIBP feature bit)
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU microcode is known to cause stability problems: NO (model 0x3c family 0x6 stepping 0x3 ucode 0x24 cpuid 0x306c3)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86): YES (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for kernel and firmware code)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)
> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).
A false sense of security is worse than no security at all, see --disclaimer
First, your CPU is one of those that did get microcode updates, which are indeed used, according to the output:
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for kernel and firmware code)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
On my Core2Duo, while the kernel is compiled with IBRS and IBPB support, neither are active due to lack of microcode support.
Variants 3a and 4 are the new “SpectreNG” vulnerabilities, for which we do not have microcode updates at this point, so it is normal they show up as vulnerable.
1 Like
Those that are showing up as yes(IBRS) were initially no before installing microcode. This is the only thing that changed due to the installation- before my system showed vulnerable to variant 3 and 4 too…
The other thing is the following:
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW
The spec_store_bypass wasn’t there before the installation…
Maybe a kernel update was also installed before the reboot? That would explain the spec_store_bypass file, which is not present on older kernels that are not SpectreNG-aware.
There was a linux-firmware update that I applied long before installing the microcode. But seriously why would that change things?
Not sure if linux-firmware would do that, but depending on your condiguration, security updates are installed automatically in the background.
So probably the kernel security update for the whole SpectreNG mess was installed in the background before the reboot.
I’m gonna uninstall the microcode and see what happens to the spec_store_bypass file, whether it comes up or not…
I’m sure that won’t make a difference. That file comes from the kernel.
Then what to do here? Do you get a spec_store_bypass vulnerability as well?
I do with the latest kernel.
And there really isn’t anything for you to do. The microcode is installed and being used to mitigate the original spectre/meltdown bugs , we’re now all waiting for Intel to release new microcode to handle the new ones as well.
You might be right- I booted from my older kernel(4.15.0-20) and there I found no spec_store_bypass message; I even got the TSC bug message even though microcode was installed…
One other thing, I mentioned a link above related to the removal of driver detection. Since it was removed for dependency issues, might it cause problem in the future on devices that have microcode installed(like you and me)?
If they do it right (i.e. have the microcode packages be a hard dependency of all relevant kernels) then it’s fine.
However, it seems right now that for some kernels this was forgotten, so they are not installed automatically.
Assuming they fix this and add the dependency correctly on the next kernel update it will then drag along the new dependency and install the microcode updates.
If you already installed them manually, they will be kept anyway.
1 Like
Is this the reason why the kernel didn’t load the latest microcode that I downloaded and installed?
Depends on how you installed it. If you just ran “apt install intel-microcode” that should also install the software needed to load the microcode if it’s not installed already.
If you download the microcode file from Intel’s website and just unpack it at the correct location, that might be missing.
I installed it using “apt-get install intel-microcode”. The tool was also installed for loading, but for some reason the kernel didn’t load this one…
