According to the Intel microcode update which was released on 2018-03-12 to address Spectre/Meltdown, the microcode is not compatible with CentOS 6.

Therefore, systems running CentOS 6 remain vulnerable to Spectre Variant 2 as CentOS maintainers delegated responsibility for this patch to upstream vendors (aka Intel).

We have installed all available OS updates and this has successfully patched against Spectre Variant 1 and Meltdown on CentOS 6 systems.

Output from running https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh:

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 2.6.32-696.23.1.el6.x86_64 #1 SMP Tue Mar 13 22:44:18 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates IBRS capability:  NO
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO
    * CPU indicates IBPB capability:  NO
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates STIBP 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 microcode is known to cause stability problems:  NO  (model 58 stepping 9 ucode 31)
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec:  NO
* Kernel has the Red Hat/Ubuntu patch:  YES
> STATUS:  NOT VULNERABLE  (Mitigation: Load fences)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  YES
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  YES
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  UNKNOWN
> STATUS:  VULNERABLE  (Vulnerable: Retpoline with unsafe module(s))

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Running as a Xen PV DomU:  NO

A false sense of security is worse than no security at all, see --disclaimer

This is the same on multiple systems running CentOS 6.9.

How can we patch a system running CentOS 6 against Spectre variant 2?


Seriously, you can just completely ignore the list of operating system compatibility from Intel's download center, at least for the microcode distribution. It is worth absolutely nothing.

The microcode update package is compatible with everything that takes Intel microcode updates. That thing has not seen a relevant change on its ABI in a decade and a half.

Whether the kernel in CentOS 6.9 will make use of the new features introduced by the microcode update is a separate matter, and even if it didn't, it would not make it incompatible with the microcode update, either.

For that matter, their instructions on how to upload the microcode to the processor are also completely wrong (the kernel has NEVER been able to handle their text-based format).

Assuming you can't just get a SRPM of the intel-microcode update from other branch of CentOS and rebuild, you can just install an old one, and replace the microcode data files installed by the RPM with the equivalent ones in the intel tarball. Don't forget to rebuild the initramfs/initrd and reboot to apply the update early.

Or you can wait, CentOS will publish an update eventually, as will everyone else. Most (all?) distros have these updates in their unstable or beta-testing branches already, and they will migrate to their stable releases eventually (timing depends on the distro).

| improve this answer | |
  • Do you have instructions on how to update the microcode properly? We've tried Intel's steps by copying microcode.dat and then reloading it with microcode_ctl - that process seems to succeed according to the output from microcode_ctl, but the microcode does not get updated (according to /proc/cpuinfo) on most (but not all) of our CentOS 6 servers. – Chris Mar 28 '18 at 11:47
  • Look at the kernel log (dmesg), it will tell you if the update took or not, and unlike the output of any userspace tool, it will be the definitive answer. – anonymous Mar 28 '18 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.