3

I installed latest stable kernel 4.14.14 from ELRepo which seems to have some fix for the Spectre vulnerability.

The changelog says there is some CONFIG_RETPOLINE in /boot/config-4.14.14-1.el7.elrepo.x86_64 file which enables the Spectre mitigation feature and which seems to be yes in my case.

But when I run this script to check what all things are fixed I don't see too much difference between the output in 4.14.13 and 4.14.14 kernel. Is this retpoline feature really enabled and if so then how to verify that?

4.14.13 output enter image description here

4.14.14 output enter image description here

I'm also interested in information about which spectre variant protection is available in 4.14.14 and in coming feature kernels.

  • 1
    Which distribution are you using, and which repository did you get your kernel from? Since you’re presumably running RHEL or CentOS, if you used the default distribution kernel, you’d be OK — they include Spectre mitigations (if you have upgraded micro-code which appears to be the case here). – Stephen Kitt Jan 18 '18 at 13:44
  • 1.14.14? What am I missing? – yeti Jan 18 '18 at 17:22
  • @StephenKitt its the centos 7.3 distribution and we are not using the default kernel 3.10.x since its too old. – mchawre Jan 18 '18 at 18:31
3

It looks like you have done pretty much all you can at the moment with the vanilla (or ElRepo) kernels.

The distribution kernels, although they may be nominally older version, might well include more security patches - ones that have not yet made their way into the vanilla kernel. In particular, the enterprise distributions are currently hard at work with probably insider information from the CPU manufacturers and their own development resources, getting the fixes into working shape and released. In this situation, the latest vanilla kernel is not necessarily the best choice.

According to the script output on 4.14.13 kernel, your processor could benefit from a microcode update. An updated microcode would enable IBRS, which is one way to mitigate Spectre Variant 2. To actually use the IBRS would require further kernel patches, which are currently under review and might or might not be included to the 4.15 kernel (and then likely backported to older kernel versions)..

With the 4.14.14, the kernel provides the CONFIG_RETPOLINE option, which can be used to mitigate Spectre Variant 2 with or without IBRS, but with the current compiler version it cannot yet implement retpolines for full effect. But although the current retpoline status is still vulnerable, it's better than nothing.

The mitigation of Spectre Variant 1 also requires compiler modifications.

So, you are now primarily waiting for a C compiler update that would enable you (or ElRepo) to compile a kernel with more LFENCE instructions in appropriate locations, and with a more stringent retpoline implementation. Those would mitigate both Spectre variants, although full retpolines for Variant 2 can eat up some CPU performance.

Secondarily, you're waiting for a (bug-free) microcode update for your CPU that would enable IBRS and a kernel update to actually use it. That could come along a BIOS/firmware update, or you could have Linux install the updated microcode at boot.

Update: Debian has provided updated compiler packages with the full retpoline functionality integrated. For Debian 8 (jessie), gcc-4.9 with retpoline backports was released in 2018-02-17, and for Debian 9 (stretch), gcc-6 with retpoline backports was released in 2018-02-22.

Also on 2018-02-22, Debian released a kernel update for Debian 9 with full retpoline mitigation for Spectre Variant 2 and an array_index_mask_nospec mitigation for Spectre Variant 1. So a full set of Spectre mitigations is now available on Debian 9, with no need for BIOS/microcode updates.

Some tests suggest that this retpoline mitigation actually has significantly less performance impact than the microcode-based one offered by Intel.

So the backport effort for the required compiler features is proceeding. Unfortunately the standard compiler version for RHEL/CentOS 7 is gcc-4.8.5: the availability of backport patches for gcc-4.9 might be of some assistance, but still more work is required to get the necessary compiler features backported all the way to gcc-4.8.5.

On 2018-02-20, Intel published a set of recommendations on microcode updates for various processor models. It also lists the microcode versions released in January that have been since then found to be buggy and accordingly recommends that any deployment of those specific microcode versions should be stopped.

  • The original poster said s/he's "installed the latest stable kernel", which makes it quite likely s/he's compiling his/her own kernels. – telcoM Jan 18 '18 at 15:35
  • That's true, I assumed that the OP had a reason to stay with vanilla kernels, which is not necessarily true nor helpful for other readers. I edited the beginning of my answer - how's that now? – telcoM Jan 18 '18 at 16:02
  • @telcoM I don't compiled the kernel its the vanilla kernel kernel.org – mchawre Jan 18 '18 at 18:27
  • @telcoM where do I track the release of gcc compiler, so that I can incorporate it soon. – mchawre Jan 19 '18 at 9:01
  • As far as I know, kernel.org provides the vanilla kernel only in the kernel source code form: you'll need to compile (build) it to get an executable kernel. I don't know where the compiler releases could be tracked regarding this case. The vanilla compiler with the patches will be almost certainly gcc-7.2 series, which could be quite a bit newer than what the enterprise distributions have. So the enterprise distros will probably do backports, to match the gcc version level on those distros. – telcoM Jan 19 '18 at 9:51

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.