RHEL 5 Support

[cvergils]

Can we get an updated version to support RHEL 5 now that the patches are available via Red Hat?

$ uname -a Linux hostname.local 2.6.18-426.el5 #1 SMP Wed Feb 7 11:05:23 EST 2018 x86_64 x86_64 x86_64 GNU/Linux $ sudo ./spectre-meltdown-check.sh --batch CVE-2017-5753: VULN (Kernel source needs to be patched to mitigate the vulnerability) CVE-2017-5715: VULN (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754: OK (PTI mitigates the vulnerability)

RHEL Fix: https://access.redhat.com/errata/RHSA-2018:0292

[speed47]

I have a dev branch exactly for this, could you try it ? It's the redhat_canonical branch. ( https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/redhat_canonical/spectre-meltdown-checker.sh )

[speed47]

Released in v0.35

[cvergils]

I tested that and it still doesn't appear to reflect the proper state. This is tested on a system that I believe to be in a "finished" state. The updated microcode version and kernel are installed.

[username@server_xyz spectre-meltdown]$ rpm -qa | egrep "kernel|microcode_ctl" | sort -rn | head -2 microcode_ctl-1.17-7.el5 kernel-2.6.18-426.el5 [username@server_xyz spectre-meltdown]$ sudo ./spectre-meltdown-check.sh --batch CVE-2017-5753: VULN (Kernel source needs to be patched to mitigate the vulnerability) CVE-2017-5715: VULN (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754: OK (PTI mitigates the vulnerability)

[speed47]

can you post the full output of the script, with the -v option ?

[cvergils]

[username@server_xyz spectre-meltdown]$ sudo ./spectre-meltdown-check.sh -v Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system Kernel is Linux 2.6.18-426.el5 #1 SMP Wed Feb 7 11:05:23 EST 2018 x86_64 CPU is Intel(R) Xeon(R) CPU E5-4620 0 @ 2.20GHz Will use vmlinux image /boot/vmlinuz-2.6.18-426.el5 Will use kconfig /boot/config-2.6.18-426.el5 Will use System.map file /proc/kallsyms

Hardware check

• Hardware support (CPU microcode) for mitigation techniques
  • Indirect Branch Restricted Speculation (IBRS)
  • SPEC_CTRL MSR is available: YES
  • CPU indicates IBRS capability: NO
  • Kernel has set the spec_ctrl flag in cpuinfo: 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: YES
  • 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 45 stepping 2 ucode )
• 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'

• Kernel has array_index_mask_nospec: NO
• Kernel has the Red Hat/Ubuntu patch: NO
• Checking count of LFENCE instructions following a jump in kernel... NO (only 0 jump-then-lfence instructions found, should be >= 30 (heuristic))

  STATUS: VULNERABLE (Kernel source needs to be patched to mitigate the vulnerability)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

• Mitigation 1
  • Kernel is compiled with IBRS/IBPB support: NO
  • 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: NO
  • Kernel compiled with a retpoline-aware compiler: NO

    STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

• Kernel supports Page Table Isolation (PTI): YES
• PTI enabled and active: YES
• Performance impact if PTI is enabled
  • CPU supports PCID: NO (no security impact but performance will be degraded with PTI)
  • CPU supports INVPCID: NO (no security impact but performance will be degraded with PTI)
• Running as a Xen PV DomU: NO

  STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

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

[speed47]

OK, it seems the way they implemented it in this kernel, if they did indeed, is somehow different. However the 2.6.18-426.el5 kernel seems to be only available for Extended Life Cycle Support 5 Red Hat subscribers, so I can't get access to it to verify this by myself :/ Would you be able to drop me by e-mail just the vmlinuz file (I don't need the rest) ? Then I should be able to find out how to detect the patch, if it is indeed present in this version.

[N3WWN]

@speed47 Are you still in need of a 2.6.18-426.el5 kernel?

[speed47]

Yes ! If you have it, that would definitely help

Le 6 mars 2018 10:45:33 PM Richard Alloway notifications@github.com a écrit :

@speed47 Are you still in need of a 2.6.18-426.el5 kernel?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/speed47/spectre-meltdown-checker/issues/146#issuecomment-370939710

[N3WWN]

@speed47 I will get the vmlinuz file(s) over to you ASAP. Sorry if this is a rudimentary question, but how do I get your email address? I can't seem to find it in this repo.

[mcpondy]

@speed47 Hi, please let me know if I can help out with any files/logs etc as I would like to use this with RHEL 5 extended support.

[speed47]

That's really strange, neither I or the official extract-vmlinux script can successfully extract a parseable ELF image out from the Red Hat 5 vmlinuz files. Even binwalk doesn't seem to find anything that makes sense appart from a compressed blob that is not an ELF file. But it still contains the kernel in a way because all the strings can be found in it. This is sufficient to detect the mitigations, by looking for the specific strings Red Hat included in their patches, and using the same logic for drawing conclusions that their official detection script uses. This is available in the offset branch, if you'd like to test. I still have to verify with a lot of other kernels that this additional logic doesn't break anything.

[N3WWN]

Here is the output from the offset branch executed on CentOS 5, 6 and 7 (both 32-bit and 64-bit systems):

CentOS 5 (32-bit):

CentOS 5 (64-bit):

CentOS 6 (32-bit):

CentOS 6 (64-bit):

CentOS 7 (32-bit):

CentOS 7 (64-bit):

The main difference between the offset branch and the master branch is that the master branch doesn't detect the Variant # 1 mitigation in CentOS 5 64-bit.

Is it correct that the 32-bit version of the 64-bit CentOS 5 and 6 kernels (2.6.18 and 2.6.32) are not expected to have Variant # 1 mitigation even though 32-bit CentOS 7 does (3.10.0)?

Am I correct in thinking that Variant # 3 will not be resolved in any 32-bit kernel (due to the VM limitations of a 32-bit address space)?

Let me know if there's anything else I can do to assist! 😁

[speed47]

Thanks for testing it on those 3 systems, it helps ! First I see the ucode is always empty, I probably broke something here, will check that (most probably introduced by the BSD support also available in that branch) I don't expect to see the KPTI mitigation for 32 bits kernels anytime soon as you pointed out. As for variant1, I'll check that.

[speed47]

Would you be able to run the following command under your 6 systems? find /sys/kernel/debug/x86/ -name "*_support" -print -o -name "*_enabled" -print

[N3WWN]

@speed47 Regarding the ucode, I have not updated the ucode on these VMs (some don't even have the microcode_ctl package installed).

Would you like me to install the microcode_ctl package on all systems, re-run the checker, then install the newest microcode directly from Intel ( https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File?product=873 ) and re-run the checker?

As these are VMs, I don't think the microcode will actually be updated as I don't think the CPU is fully emulated in that manner - I'd probably have to update the microcode on the host system.

Regarding the checker runs on these systems, I forgot to mount /sys/kernel/debug before running the checker. I had previously mounted debugfs. I'll get that done at boot so I don't forget in the future. The CentOS 7 VMs had /sys/kernel/debug mounted, but the others didn't.

I see that the checker attempts to mount /sys/kernel/debug, so I guess the output wouldn't be any different.

Here's the output for find /sys/kernel/debug/x86/ -name "*_support" -print -o -name "*_enabled" -print on both of the 6 systems:

CentOS 6 (32-bit): no output

CentOS 6 (64-bit): /sys/kernel/debug/x86/pti_enabled /sys/kernel/debug/x86/ibpb_enabled /sys/kernel/debug/x86/ibrs_enabled

[speed47]

@N3WWN Regarding the ucode, don't bother, if you're in VMs (I didn't notice "vagrant" in your screenshots at first), some properties of the CPU are not passed through the hypervisor, depending on the hypervisor and its configuration, and the ucode version is sometimes one of those, so it's not a bug after all.

You're right, the script attempts to mount debugfs if it's not mounted already (and unounts it on exit if it did mount it, to leave the system as it was before the script was run)

The outputs you have on CentOS 6 32/64 bits do match what I find in offline analysis (inspecting the kernel image without having it booted), and it also matches what the script finds (in the offset branch) from your screenshots. This is good! For CentOS/RHEL 7 I'm pretty sure to know what the output will be. However it would be interesting to test on CentOS/RHEL 5 both 32/64 bits.

If the script is right, you should get nothing for CentOS 5 32 bits, and only pti_enabled in debugfs for CentOS 5 64 bits.

[N3WWN]

@speed47 Thanks for confirming that ucode updates wouldn't be useful due to being virtualized.

As requested, here's the output for find /sys/kernel/debug/x86/ -name "*_support" -print -o -name "*_enabled" -print on both of the 5 systems:

CentOS 5 (32-bit): find: /sys/kernel/debug/x86/: No such file or directory

CentOS 5 (64-bit): /sys/kernel/debug/x86/pti_enabled

This output is exactly as you prophesied! 🔮

😀

[speed47]

Perfect ! I'm releasing v0.36 then ;)

[speed47]

Assuming that we can close this. Feel free to reopen if needed!