Spectre And Meltdown Detector

Updated -

This tool is designed to detect Spectre and Meltdown in Red Hat Enterprise Linux 5 or later.
You must contact your hardware OEM to receive the appropriate microcode/firmware for your processor that will enable the protections for Variant 2 of this issue.
For more information about Spectre and Meltdown, read these articles:
Kernel Side-Channel Attacks - CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables

Was this helpful?

Yes No
We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.

Get notified when this content is updated

Follow

Share

Red Hat Customer Portal Twitter Facebook

23 Comments

Subscriber exclusive content

An active Red Hat subscription is required to participate.

Log In
Christian Labisch's picture Guru 35315 points
16 January 2018 2:38 PM

This is really a very useful tool, it would be nice if the security team could provide a version that will run on supported fedora systems as well.
Why do I ask ? Simply because fedora is part of the Red Hat universe and - because I prefer in-house solutions in favour of third party ones. :)

Regards,
Christian

DZ Red Hat Community Member 41 points
18 January 2018 3:08 AM

Hi Christian, Thanks for reaching out. The app/script works by checking messages and debug values in RHEL, and those may not exist on Fedora. The goal of the app is to help Red Hat customers to detect issues on their RHEL systems. Security team does not have a plan to create tools for Fedora.
For Fedora, you need to find tools/scripts from communities. For example, here is something that may be useful, but be aware that it is not tested by Red Hat so there may be some risks https://github.com/speed47/spectre-meltdown-checker

Christian Labisch's picture Guru 35315 points
18 January 2018 11:25 AM

Hi Dong, Thanks for your feedback. Understood, I've already tested the spectre-meltdown-checker tool, but it seems to check 'things' a bit differently than the Red Hat script does ... because even though I am running the latest stable kernel (4.14.13-300) from the official fedora repositories, it reports both Spectre variants as not being mitigated. :)

Regards,
Christian

RG Community Member 22 points
16 January 2018 10:47 PM

we continue to fail at getting the gpg key... See below. Is there a problem? gpg: requesting key 8366B0D9 from hkp server pgp.mit.edu gpg: keyserver timed out gpg: keyserver receive failed: Keyserver error

DZ Red Hat Community Member 41 points
17 January 2018 1:33 AM

Hi Richard, The key is stored on a public key server. Please check your internet connectability and make sure your system is able to connect to it. Many of Red Hat customers has been using this key and we have not heard anyone else report the same failure.

Thanks, Dong Zhao

yy Community Member 36 points
17 January 2018 11:29 AM

On RHEL6 systems with latest kernel and RedHat microcode / firmware applied (prior to latest reversion) - I'm seeing :

Variant #3 (Meltdown): Vulnerable
CVE-2017-5754 - speculative execution permission faults handling
   - Kernel with mitigation patches: OK
   - PTI: Not disabled on kernel commandline

running_kernel = *2.6.32-696.18.7.el6.x86_64*
rhel = *6*
vendor = *Intel*
root = *1*
mounted_debugfs = *0*
all_debug_files = *0*
fallback_needed = *1*
pti_debugfs = *0*
ibrs_debugfs = *0*
ibpb_debugfs = *0*
dmesg_wrapped = *0*
pti_dmesg = *0*
ibrs_dmesg = *0*
ibpb_dmesg = *0*
new_kernel = *1*
nopti_cmd = *0*
noibrs_cmd = *0*
noibpb_cmd = *0*
hw_support = *0*
variant_1 = *Mitigated*
variant_2 = *Vulnerable*
variant_3 = *Vulnerable*

Manually running:

dmesg | grep  'x86/pti'
x86/pti: Kernel page table isolation enabled

The script is however grepping for 'x86/pti: Unmapping kernel while in userspace'

Is my system still vulnerable then as indicated to Variant #3 (Meltdown) ?

Stanislav Kontar's picture Red Hat Community Member 37 points
17 January 2018 1:42 PM

We are looking into it at the moment. In the meantime, can you try to mount debugfs? The detection should be more reliable.

yy Community Member 36 points
17 January 2018 2:17 PM

Thanks - yes with debugfs mounted, I get that Variant 3 is Mitigated.

~]$ sudo mount -t debugfs nodev /sys/kernel/debug
~]$ sudo ./spectre.sh -d

This script is primarily designed to detect Spectre / Meltdown on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

running_kernel = *2.6.32-696.18.7.el6.x86_64*
rhel = *6*
vendor = *Intel*
root = *1*
mounted_debugfs = *1*
all_debug_files = *1*
fallback_needed = *0*
pti_debugfs = *1*
ibrs_debugfs = *0*
ibpb_debugfs = *0*
dmesg_wrapped = *0*
pti_dmesg = *0*
ibrs_dmesg = *0*
ibpb_dmesg = *0*
new_kernel = *1*
nopti_cmd = *0*
noibrs_cmd = *0*
noibpb_cmd = *0*
hw_support = *0*
variant_1 = *Mitigated*
variant_2 = *Vulnerable*
variant_3 = *Mitigated*

Detected CPU vendor: Intel
Running kernel: 2.6.32-696.18.7.el6.x86_64

Variant #1 (Spectre): Mitigated
CVE-2017-5753 - speculative execution bounds-check bypass
   - Kernel with mitigation patches: OK

Variant #2 (Spectre): Vulnerable
CVE-2017-5715 - speculative execution branch target injection
   - Kernel with mitigation patches: OK
   - HW support / updated microcode: NO
   - IBRS: Not disabled on kernel commandline
   - IBPB: Not disabled on kernel commandline

Variant #3 (Meltdown): Mitigated
CVE-2017-5754 - speculative execution permission faults handling
   - Kernel with mitigation patches: OK
   - PTI: Not disabled on kernel commandline

Is mounting debugfs on a production system a bad idea?

Stanislav Kontar's picture Red Hat Community Member 37 points
18 January 2018 10:16 AM

The script has been updated to take different RHEL6 dmesg messages into account. Thanks for letting us know!

John Westerdale's picture Pro 562 points
7 February 2018 4:06 AM

Is mounting debugfs and running the script safe on an active production server?

Stanislav Kontar's picture Red Hat Community Member 37 points
7 February 2018 1:07 PM

Mounting debugfs is not recommended on active production server (if it is not mounted by default).

John Westerdale's picture Pro 562 points
3 August 2018 7:29 PM

Is there a safe way to get a positive confirmation from a production server while its in service?

Stanislav Kontar's picture Red Hat Community Member 37 points
14 August 2018 7:34 AM

Hi. I think that the latest detection script should work fairly well even on RHEL6 with debugfs unmounted. Especially if the kernel was updated to the version which provides the information in /sys/devices/system/cpu/vulnerabilities .

Nikita GOLOVIN's picture
29 January 2018 12:53 PM

The script doesn't work properly without sudo on some servers I have.

The problem is: without sudo, it fails to recognize that the latest kernel fixes some of the vulnerabilities.

With sudo, it works properly.

Tested with RHEL7.3 and the kernel from the: https://access.redhat.com/errata/RHSA-2018:0009

Stanislav Kontar's picture Red Hat Community Member 37 points
29 January 2018 1:06 PM

Hi Nikita. When the script is ran without sudo it uses a fallback detection from dmesg messages. That may be unreliable in some cases, as dmesg is circular buffer which may wrap when the server is running for a long time. If you believe that it is not the case, please email to secalert@redhat.com . Ran the script with --debug commandline option, both as normal user and root, and provide the output. Thanks!

Nikita GOLOVIN's picture
29 January 2018 1:22 PM

Thank you for the clarifications!

In the instance, the server had only 2 days of uptime

Will do further investigations with the --debug later

TH Active Contributor 201 points
5 February 2018 12:58 PM

Is it just me or are the following files the same and thus the second is not the signature? https://access.redhat.com/labs/speculativeexecution/spectre_meltdown.sh https://access.redhat.com/labs/speculativeexecution/spectre_meltdown.sh.asc I did the following: wget https://access.redhat.com/labs/speculativeexecution/spectre_meltdown.sh wget https://access.redhat.com/labs/speculativeexecution/spectre_meltdown.sh.asc md5sum spectre_meltdown.sh* 8dc186353d44fdabea709b0c26d61c52 spectre_meltdown.sh 8dc186353d44fdabea709b0c26d61c52 spectre_meltdown.sh.asc ... never mind. I guess I can't use wget to pull those down. If I click on the links and download in browser then they are correct.

MP Newbie 10 points
16 March 2018 7:52 AM

Script displays that my system is fully mitigated with kernel 2.6.32-696.20.1.el6.x86_64 but vulnerable with newer kernel 2.6.32-696.23.1.el6.x86_64 ? (VMware with fixed BIOS and ESX)

Detected CPU vendor: Intel Running kernel: 2.6.32-696.20.1.el6.x86_64

Variant #1 (Spectre): Mitigated CVE-2017-5753 - speculative execution bounds-check bypass - Kernel with mitigation patches: OK

Variant #2 (Spectre): Mitigated CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: YES - IBRS: Not disabled on kernel commandline - IBPB: Not disabled on kernel commandline

Variant #3 (Meltdown): Mitigated CVE-2017-5754 - speculative execution permission faults handling - Kernel with mitigation patches: OK - PTI: Not disabled on kernel commandline

#

Detected CPU vendor: Intel Running kernel: 2.6.32-696.23.1.el6.x86_64

Variant #1 (Spectre): Mitigated CVE-2017-5753 - speculative execution bounds-check bypass - Kernel with mitigation patches: OK

Variant #2 (Spectre): Vulnerable CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: YES - IBRS: Not disabled on kernel commandline - IBPB: Not disabled on kernel commandline

Variant #3 (Meltdown): Vulnerable CVE-2017-5754 - speculative execution permission faults handling - Kernel with mitigation patches: OK - PTI: Not disabled on kernel commandline

Stanislav Kontar's picture Red Hat Community Member 37 points
20 March 2018 8:27 PM

We are working on the script updates so it recognizes the newest patches, unfortunately it is not done yet.

PO Newbie 16 points
29 May 2018 6:14 AM

Please be aware that currently (May, 29th) the script located under https://access.redhat.com/labs/speculativeexecution/ ist still V2.5. A newer release is located under https://access.redhat.com/security/vulnerabilities/speculativeexecution . There you can find V2.6.

Regards, Peter.

Christian Labisch's picture Guru 35315 points
29 May 2018 6:47 AM

Thank you for the information, Peter ! :)

Regards,
Christian

PO Newbie 16 points
27 August 2018 10:10 AM

A newer version is available: V2.8 (s. the Link in my former post).

DZ Red Hat Community Member 41 points
28 August 2018 12:37 AM

Scripts provided at the two places are identical. Both are v2.8.