RHEL/CentOS 7.4 kernel-3.10.0-693.21.1.el7.x86_64 changes

[knweiss]

FWIW: Red Hat introduced retpoline support in the latest RHEL 7.4 kernel 3.10.0-693.21.1.el7.x86_64 update:

# spectre-meltdown-checker  --no-color  
Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system
Kernel is Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz

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 63 stepping 2 ucode 0x3a)
* 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: NO
* Mitigation 2
  * Kernel compiled with retpoline option: YES
  * Kernel compiled with a retpoline-aware compiler: UNKNOWN
> STATUS: VULNERABLE (Vulnerable: Retpoline without IBPB)

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
> STATUS: NOT VULNERABLE (Mitigation: PTI)

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

(Notice the UNKNOWN Status in "Kernel compiled with a retpoline-aware compiler:" above!)

They also backported retpoline support to gcc-4.8.5 (which was also updated):

# rpm -qiv gcc-4.8.5-16.el7_4.2.x86_64 --changelog | grep -B1 retpoline
* Wed Jan 24 2018 Jeff Law <law@redhat.com> 4.8.5-16.2
- retpoline support for spectre mitigation (#1538487)

There are also changes in some of the /sys files:

• The vulnerabilities/ directory does exist now:

  # grep . /sys/devices/system/cpu/vulnerabilities/*
  /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
  /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load fences
  /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Retpoline without IBPB

• The ibpb_enabled permissions changed and the retp_enabled file is new:

  # ls -l /sys/kernel/debug/x86/*enabled
  -r--------. 1 root root 0 Mar 12 09:55 /sys/kernel/debug/x86/ibpb_enabled
  -rw-------. 1 root root 0 Mar 12 09:55 /sys/kernel/debug/x86/ibrs_enabled
  -rw-------. 1 root root 0 Mar 12 09:19 /sys/kernel/debug/x86/pti_enabled
  -rw-------. 1 root root 0 Mar 12 09:19 /sys/kernel/debug/x86/retp_enabled

[k-nakayama-pg]

I have the same problem.

[janvitos]

Same thing here. Any updates on this?

[speed47]

@kneiss thanks for the data. I'm finalizing support for RHEL 5 to get version 0.36 out, then I'll implement the new things that appeared in RHEL 7. @k-nakayama-pg @janvitos what problem are your referring to ? The fact that retpoline-aware compiled is UNKNOWN, or are your referring to something else?

[speed47]

I've pushed a new test branch newibpb taking into account the retp_enabled tunable of Red Hat, and also latest changes in vanilla kernels. Can you try it ? ( https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/newibpb/spectre-meltdown-checker.sh )

[knweiss]

IMHO the (minor) issue here is that the check is called Kernel compiled with a retpoline-aware compiler but it only works if the kernel is compiled with a retpoline-aware compiler and retpoline is actually enabled:

# grep . /sys/kernel/debug/x86/*_enabled
/sys/kernel/debug/x86/ibpb_enabled:0
/sys/kernel/debug/x86/ibrs_enabled:0
/sys/kernel/debug/x86/pti_enabled:1
/sys/kernel/debug/x86/retp_enabled:0
# ./spectre-meltdown-checker_branch_newibpb.sh --no-color|grep "retpoline-aware"
    * Kernel compiled with a retpoline-aware compiler: UNKNOWN
# echo "1" >/sys/kernel/debug/x86/retp_enabled
# ./spectre-meltdown-checker_branch_newibpb.sh --no-color|grep "retpoline-aware"
    * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)

The name of the check IMHO suggests that it should work independent of the retpoline activation status.

However the old version 0.36 even showed "UNKNOWN" if retpoline is active:

# echo "1" >/sys/kernel/debug/x86/retp_enabled
# spectre-meltdown-checker | egrep 'tool|retpoline-aware'
Spectre and Meltdown mitigation detection tool v0.36
  * Kernel compiled with a retpoline-aware compiler:  UNKNOWN 

[speed47]

@knweiss This is actually why it says "unknown" and not "no" ;) because on somehow recent kernels, detecting a retpoline-aware compiler is almost impossible without having this kernel booted and retpoline activated, as when this is the case, the kernel reports whether it was compiled with retpoline-aware compiler or not, and doesn't if retpoline is not enabled. On the first versions of the retpoline patches, this was easier to detect just given the offline kernel image, as some symbols were there if it was the case. This is no longer the case. If this seems strange, I might as well completely hide this test if the value can't be determined ? Would this make it more clear ?

[knweiss]

@speed47 Yes, I think this would avoid the confusion. Maybe you could still print it in verbose mode.

Alternative: Change "UNKNOWN" into "UNKNOWN (either NO or INACTIVE)".

[knweiss]

(Does the file /sys/kernel/debug/x86/retp_enabled really exist on a Red Hat kernel that was compiled with a retpoline-unaware compiler but who's source has retpoline support?

In other words: Couldn't the existence of this file be used as an indicator for a retpoline-aware compiler even if retpoline support is inactive (at least on Red Hat)?)

[speed47]

@knweiss removed the line when it would be UNKNOWN.

As for retp_enabled, I'm almost sure it also exists when the compiler was not retpoline-aware, by looking at the source code (the value of spectre_v2 in sysfs would then be Vulnerable: Minimal ASM retpoline)

[orachas]

Please take a look at my final comment on issue #181 - there are better alternatives to the Red Hat stock kernel for retpoline support, especially on older CPUs where microcode is not available.

[kuzetsa]

[...] alternatives to the Red Hat stock kernel for retpoline support, especially on older CPUs where microcode is not available.

I hadn't even considered that the RHEL 7.x series started using the 3.10 branch in 2015 or so, and it's still the "current" kernel on RHEL 7.x OS versions: When I titled #181, I was only thinking about upstream / kernel.org support (for example, on 4.15.x series kernels) for a more robust retpoline-based mitigation.

Because the level of security available in RHEL's retpoline (and the requirement to use updated microcode for better coverage) on 3.10.x kernels wasn't even on my radar, and there are plenty of kernels which get their retpoline from a distro patchset in this way
. basically I'm yielding to people like @orachas and @speed47 who know more about RHEL, and/or other distro kernels.

(oops. the research and ideas behind #181 could be irrelevant if you're using a RHEL kernel.)

[speed47]

Closing this, as the discussion seems to have dried out and the original issue is fixed ;)