speed47 / spectre-meltdown-checker

Reptar, Downfall, Zenbleed, ZombieLoad, RIDL, Fallout, Foreshadow, Spectre, Meltdown vulnerability/mitigation checker for Linux & BSD

Spectre & Meltdown Checker

A shell script to assess your system's resilience against the several transient execution CVEs that were published since early 2018, and give you guidance as to how to mitigate them.

CVE	Name	Aliases
CVE-2017-5753	Bounds Check Bypass	Spectre Variant 1
CVE-2017-5715	Branch Target Injection	Spectre Variant 2
CVE-2017-5754	Rogue Data Cache Load	Meltdown, Variant 3
CVE-2018-3640	Rogue System Register Read	Variant 3a
CVE-2018-3639	Speculative Store Bypass	Variant 4
CVE-2018-3615	L1 Terminal Fault	L1TF, Foreshadow (SGX)
CVE-2018-3620	L1 Terminal Fault	L1TF, Foreshadow-NG (OS)
CVE-2018-3646	L1 Terminal Fault	L1TF, Foreshadow-NG (VMM)
CVE-2018-12126	Microarchitectural Store Buffer Data Sampling	MSBDS, Fallout
CVE-2018-12130	Microarchitectural Fill Buffer Data Sampling	MFBDS, ZombieLoad
CVE-2018-12127	Microarchitectural Load Port Data Sampling	MLPDS, RIDL
CVE-2019-11091	Microarchitectural Data Sampling Uncacheable Memory	MDSUM, RIDL
CVE-2019-11135	TSX asynchronous abort	TAA, ZombieLoad V2
CVE-2018-12207	Machine Check Exception on Page Size Changes	MCEPSC, No eXcuses, iTLB Multihit
CVE-2020-0543	Special Register Buffer Data Sampling	SRBDS
CVE-2022-40982	Gather Data Sampling	GDS, Downfall
CVE-2023-20569	Return Address Security	Inception, RAS, SRSO
CVE-2023-20593	Cross-Process Information Leak	Zenbleed
CVE-2023-23583	Redundant Prefix issue	Reptar

Supported operating systems:

• Linux (all versions, flavors and distros)
• FreeBSD, NetBSD, DragonFlyBSD and derivatives (others BSDs are not supported)

For Linux systems, the tool will detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number and the distribution (such as Debian, Ubuntu, CentOS, RHEL, Fedora, openSUSE, Arch, ...), it also works if you've compiled your own kernel. More information here.

Other operating systems such as MacOS, Windows, ESXi, etc. will most likely never be supported.

Supported architectures:

• x86 (32 bits)
• amd64/x86_64 (64 bits)
• ARM and ARM64
• other architectures will work, but mitigations (if they exist) might not always be detected

Frequently Asked Questions (FAQ)

• What is the purpose of this tool?
• Why was it written?
• How can it be useful to me?
• How does it work?
• What can I expect from it?

All these questions (and more) have detailed answers in the FAQ, please have a look!

Easy way to run the script

• Get the latest version of the script using curl or wget

curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
wget https://meltdown.ovh -O spectre-meltdown-checker.sh

• Inspect the script. You never blindly run scripts you downloaded from the Internet, do you?

vim spectre-meltdown-checker.sh

• When you're ready, run the script as root

chmod +x spectre-meltdown-checker.sh
sudo ./spectre-meltdown-checker.sh

Run the script in a docker container

With docker-compose

docker-compose build
docker-compose run --rm spectre-meltdown-checker

Without docker-compose

docker build -t spectre-meltdown-checker .
docker run --rm --privileged -v /boot:/boot:ro -v /dev/cpu:/dev/cpu:ro -v /lib/modules:/lib/modules:ro spectre-meltdown-checker

Example of script output

• Intel Haswell CPU running under Ubuntu 16.04 LTS

• AMD Ryzen running under OpenSUSE Tumbleweed

• Batch mode (JSON flavor)

Quick summary of the CVEs

CVE-2017-5753 bounds check bypass (Spectre Variant 1)

• Impact: Kernel & all software
• Mitigation: recompile software and kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code
• Performance impact of the mitigation: negligible

CVE-2017-5715 branch target injection (Spectre Variant 2)

• Impact: Kernel
• Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
• Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
• Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU

CVE-2017-5754 rogue data cache load (Meltdown)

• Impact: Kernel
• Mitigation: updated kernel (with PTI/KPTI patches), updating the kernel is enough
• Performance impact of the mitigation: low to medium

CVE-2018-3640 rogue system register read (Variant 3a)

• Impact: TBC
• Mitigation: microcode update only
• Performance impact of the mitigation: negligible

CVE-2018-3639 speculative store bypass (Variant 4)

• Impact: software using JIT (no known exploitation against kernel)
• Mitigation: microcode update + kernel update making possible for affected software to protect itself
• Performance impact of the mitigation: low to medium

CVE-2018-3615 l1 terminal fault (Foreshadow-NG SGX)

• Impact: Kernel & all software (any physical memory address in the system)
• Mitigation: microcode update
• Performance impact of the mitigation: negligible

CVE-2018-3620 l1 terminal fault (Foreshadow-NG SMM)

• Impact: Kernel & System management mode
• Mitigation: updated kernel (with PTE inversion)
• Performance impact of the mitigation: negligible

CVE-2018-3646 l1 terminal fault (Foreshadow-NG VMM)

• Impact: Virtualization software and Virtual Machine Monitors
• Mitigation: disable ept (extended page tables), disable hyper-threading (SMT), or updated kernel (with L1d flush)
• Performance impact of the mitigation: low to significant

CVE-2018-12126 [MSBDS] Microarchitectural Store Buffer Data Sampling (Fallout)

CVE-2018-12130 [MFBDS] Microarchitectural Fill Buffer Data Sampling (ZombieLoad)

CVE-2018-12127 [MLPDS] Microarchitectural Load Port Data Sampling (RIDL)

CVE-2019-11091 [MDSUM] Microarchitectural Data Sampling Uncacheable Memory (RIDL)

• Note: These 4 CVEs are similar and collectively named "MDS" vulnerabilities, the mitigation is identical for all
• Impact: Kernel
• Mitigation: microcode update + kernel update making possible to protect various CPU internal buffers from unprivileged speculative access to data
• Performance impact of the mitigation: low to significant

CVE-2019-11135 TSX Asynchronous Abort (TAA, ZombieLoad V2)

• Impact: Kernel
• Mitigation: microcode update + kernel update making possible to protect various CPU internal buffers from unprivileged speculative access to data
• Performance impact of the mitigation: low to significant

CVE-2018-12207 machine check exception on page size changes (No eXcuses, iTLB Multihit)

• Impact: Virtualization software and Virtual Machine Monitors
• Mitigation: disable hugepages use in hypervisor, or update hypervisor to benefit from mitigation
• Performance impact of the mitigation: low to significant

CVE-2020-0543 Special Register Buffer Data Sampling (SRBDS)

• Impact: Kernel
• Mitigation: microcode update + kernel update helping to protect various CPU internal buffers from unprivileged speculative access to data
• Performance impact of the mitigation: low

CVE-2022-40982 Gather Data Sampling (GDS, Downfall)

• Impact: Kernel & all software
• Mitigation: either microcode update or disabling AVX feature
• Performance impact of the mitigation: TBD

CVE-2023-20569 Return Address Security (Inception)

• Impact: Kernel & all software
• Mitigation: updated kernel & microcode
• Performance impact of the mitigation: low to significant depending on the mitigation

CVE-2023-20593 Cross-Process Information Leak (Zenbleed)

• Impact: Kernel & all software
• Mitigation: either kernel mitigation by disabling a CPU optimization through an MSR bit, or CPU microcode mitigation
• Performance impact of the mitigation: TBD

CVE-2023-23583 Redundant Prefix issue (Reptar)

• Impact: All software
• Mitigation: microcode update for the affected CPU
• Performance impact of the mitigation: low

spectre-meltdown-checker's Issues

Incorrect AMD not vulnerable flag?

The code in is_cpu_vulnerable() for AMD CPUs sets

variant1=0

Shouldn't this be variant3 a.k.a. Meltdown?

Possible false result

After having applied every update (inncluding BIOS) that I'm aware of these are now my results:

However, this Spectre POC from crozone still executes successfully.

Is the tool falsely reporting that I am not vulnerable, or is the POC no good?

Assumptions about grep

Variant 3 will return a false positive on some ARM-based Android systems that implement busybox, because /system/bin/grep is rather brain dead and cannot handle the following:

grep -qi 'CPU implementer : 0x41' /proc/cpuinfo

However, using the grep that is installed as part of busybox does function properly.

The script makes assumptions about grep that may not hold true on all Linux variants. Please consider implementing some way to override the grep command in the script to allow the use of 'busybox grep' instead. It is possible to do a search and replace, but some of the variables have grep in their name, and this must be done carefully.

Script in guest KVM

Hi, I have run the script in a guest KVM/QEMU CentOS 7 machine, I have seen that all is ok but the variant 2 it's not corrected because I have not activated IBRS and I have noted that this is not posible because no microcode update for QEMU emulated CPU it's available. The question is if the script result is a false positive or not?

Intel Atom N270 series cpus are not identified as such

The script checks for the presence of an older Atom cpu in line 174 by grepping for the 'Atom' string in the /proc/cpuinfo output.

However, an Atom string is not present for the N270 model which is reported as:

model name : Genuine Intel(R) CPU N270 @ 1.60GHz

As such the check should probably be revised to look for the specific Atom model designations (N270/N230/N330, et al.) as opposed to the cpu name in order to correctly flag variants 2 & 3.

SuSE Linux/AMI Linux verification

Thank you very much for this tool

Testing the tool against AMI , CentOS 7.4 and SuSE Enterprise Linux after patching with respective vendor patches. All the tests are against your tool ver 0.09. The outputs are given below. Can you please check why the vulnerabilities are reported inspite of installing the patches.

Thank you once again for the tool.

Amazon Linux

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 35 opcodes found, should be >= 60)
> STATUS:  VULNERABLE

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpolines:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines 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
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Suse Linux Enterprise Desktop/Server

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places:  YES  (91 opcodes found, which is >= 60)
> STATUS:  NOT VULNERABLE

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpolines:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO
* PTI enabled and active:  NO
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

CentOS 7.4

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places:  YES  (112 opcodes found, which is >= 60)
> STATUS:  NOT VULNERABLE

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpolines:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO
* PTI enabled and active:  NO
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Is there support for Arch Linux?

Arch linux detected as vulnerable

Hi there,

As you can see in the below output I should't be affected:

martin@marto ~]$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y

[martin@marto ~]$ dmesg | grep iso
[    0.000000] Kernel/User page tables isolation: enabled

But after running your script I see the following:

[martin@marto ~]$ sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 21 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  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 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
[martin@marto ~]$ 

I think someting is wrong here.Please advise.

mktemp may require 6 Xs on BSD-like distributions such as Slackware

mktemp on Slackware for instance follows the BSD convention of requiring 6 Xs rather than 3 Xs.

Otherwise an error message occurs:

mktemp /tmp/blah.XXX
mktemp: cannot create temp file /tmp/blah.XXX: Invalid argument

This should be a simple patch to write, and I'll submit a PR.

Feature request: Exitcodes or easy parsable output option

Hi,

Would it be possible to add exitcodes or perhaps an option for easily parsable output. When collecting output from many servers it would be nice with an easier way to get vulnerable yes/no status for each variant.

Perhaps just something like the below:

exitcode 7: vulnerable to: spectre variant 1, spectre variant2, and meltdown
exitcode 6: vulnerable to: spectre variant2 and meltdown
exitcode 5: vulnerable to: spectre variant 1 and meltdown
exitcode 4: vulnerable to: meltdown
exitcode 3: vulnerable to: spectre variant 1 and spectre variant2
exitcode 2: vulnerable to: spectre variant2
exitcode 1: vulnerable to: spectre variant 1
exitcode 0: not vulnerable to any

$ diff -u spectre-meltdown-checker.sh spectre-meltdown-checker.sh.local
--- spectre-meltdown-checker.sh	2018-01-08 14:43:28.509019256 +0100
+++ spectre-meltdown-checker.sh.local	2018-01-08 14:46:34.297937058 +0100
@@ -2,6 +2,7 @@
 # Spectre & Meltdown checker
 # Stephane Lesimple
 VERSION=0.13
+exitcode=7

 # print status function
 pstatus()
@@ -135,7 +136,7 @@
 /bin/echo -ne "> \033[46m\033[30mSTATUS:\033[0m "
 [ "$status" = 0 ] && pstatus yellow UNKNOWN
 [ "$status" = 1 ] && pstatus red VULNERABLE
-[ "$status" = 2 ] && pstatus green 'NOT VULNERABLE'
+[ "$status" = 2 ] && pstatus green 'NOT VULNERABLE' && exitcode=$((exitcode - 1))

 ###########
 # VARIANT 2
@@ -232,10 +233,13 @@
 /bin/echo -ne "> \033[46m\033[30mSTATUS:\033[0m "
 if grep -q AMD /proc/cpuinfo; then
 	pstatus green "NOT VULNERABLE" "your CPU is not vulnerable as per the vendor"
+	exitcode=$((exitcode - 2))
 elif [ "$ibrs_enabled" = 1 -o "$ibrs_enabled" = 2 ]; then
 	pstatus green "NOT VULNERABLE" "IBRS mitigates the vulnerability"
+	exitcode=$((exitcode - 2))
 elif [ "$retpoline" = 1 ]; then
 	pstatus green "NOT VULNERABLE" "retpolines mitigate the vulnerability"
+	exitcode=$((exitcode - 2))
 else
 	pstatus red VULNERABLE "IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability"
 fi
@@ -313,8 +317,10 @@
 /bin/echo -ne "> \033[46m\033[30mSTATUS:\033[0m "
 if grep -q AMD /proc/cpuinfo; then
 	pstatus green "NOT VULNERABLE" "your CPU is not vulnerable as per the vendor"
+	exitcode=$((exitcode - 4))
 elif [ "$kpti_enabled" = 1 ]; then
 	pstatus green "NOT VULNERABLE" "PTI mitigates the vulnerability"
+	exitcode=$((exitcode - 4))
 else
 	pstatus red "VULNERABLE" "PTI is needed to mitigate the vulnerability"
 fi
@@ -322,3 +328,5 @@
 /bin/echo

 [ -n "$vmlinux" -a -f "$vmlinux" ] && rm -f "$vmlinux"
+
+exit $exitcode

Need verification for results of testing the Cell CPU

Hello and thanks for this tool!

I was able to run it on a PS3 featuring the unique Cell CPU made by STI (Sony, Toshiba, IBM) and thought that this CPU is not vulnerable to Meltdown and/or Spectre.

Unfortunately my results showed the opposite:

---

Spectre and Meltdown mitigation detection tool v0.16

Checking vulnerabilities against Linux 3.12.6-red-ribbon-powerpc64-ps3 #7 SMP Tue Jan 7 17:09:59 CET 2014 ppc64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Kernel compiled with LFENCE opcode inserted at the proper places: UNKNOWN (couldn't find your kernel image in /boot, if you used netboot, this is normal)

STATUS: UNKNOWN

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: NO
• Mitigation 2
• Kernel compiled with retpoline option: NO
• Kernel compiled with a retpoline-aware compiler: UNKNOWN (couldn't find your kernel image)

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): NO
• PTI enabled and active: NO

STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

---

I rerun yesterday with version 0.31 and the results stayed the same.

I need confirmation from other users if this is really the case. It would show that IBM CPUs are also affected, so far IBM didn't state completely to what extent their CPUs are vulnerable. I read that PowerPC6 and up shouldn't be affected.

Also, please check if it's even possible that the results are of no use at all (which I deny) because the tool simply wasn't written to support the Cell.

Thanks in advance and keep on!

Some logs overwrites dmeg, grep kern.log (and possible solution)

Hi,
Some logs overwrites the kernel log output. (for intance some iptables logs) and you get a false positive about Meltdown PTI. Can you add this lines of code to grep /var/log/kern.log ? (Lines 1054 to 1057)

1050                         elif [ -r /var/log/dmesg ] && grep -Eq "$dmesg_grep" /var/log/dmesg; then
1051                                 # if we can't find the flag in dmesg output, grep in /var/log/dmesg when readable
1052                                 _debug "kpti_enabled: found hint in /var/log/dmesg: "$(grep -E "$dmesg_grep" /var/log/dmesg)
1053                                 kpti_enabled=1
1054                         elif [ -r /var/log/kern.log ] && grep -Eq "$dmesg_grep" /var/log/kern.log; then
1055                                 # if we can't find the flag in dmesg output, grep in /var/log/kern.log when readable
1056                                 _debug "kpti_enabled: found hint in /var/log/kern.log: "$(grep -E "$dmesg_grep" /var/log/kern.log)
1057                                 kpti_enabled=1
1058                         else
1059                                 _debug "kpti_enabled: couldn't find any hint that PTI is enabled"
1060                                 kpti_enabled=0

Chromebooks (Edgar) reported as vulnerable ...

Chrome is reported as patched against both Spectre and Meltdown. Results of running checker in
in developer shell listed below. This is a vanilla machine w/ dev mode enabled specifically to run checker's live test and see what the results were. Note UNKNOWN result for CVE-2017-5753 and Mitigation 2 of CVE-2017-5715. chrome://flags/#enable-site-per-process is enabled on this machine.

Checking for vulnerabilities against live running kernel Linux 3.18.0-16288-g64d05cf80004 #1 SMP 
PREEMPT Mon Jan 8 23:16:08 PST 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  UNKNOWN 
> STATUS:  UNKNOWN  (couldn't check (couldn't find your kernel image in /boot, if you used netboot, 
this is normal))

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  UNKNOWN  (couldn't read your kernel configuration)
*   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):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Xen PV silently disables pti/kaiser (was: AWS reports as vuln even after patch+reboot)

Per https://alas.aws.amazon.com/ALAS-2018-939.html, the correct kernel for AWS AMIs should be: *-4.9.75-25.55.amzn1.[arch]

$ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.9.75-25.55.amzn1.x86_64 #1 SMP Fri Jan 5 23:50:27 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: NO

STATUS: VULNERABLE (only 27 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: YES
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: 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: NO

STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

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

Anyone know why this is still showing up as vuln to all three?

Even stranger, when I first applied kernel updates via yum, I ran the tool before rebooting and it said meltdown was patched. Then I rebooted and it said all three are vuln. This paste below is PRE-reboot, note the kernel difference.

$ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.9.70-25.242.amzn1.x86_64 #1 SMP Wed Jan 3 05:36:22 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: NO

STATUS: VULNERABLE (only 27 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: YES
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: 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

STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

Error: vmlinuz not found on Fedora

Running the script with sudo on Fedora 27 prints this at the beginning:

Checking for vulnerabilities against live running kernel Linux 4.14.11-300.fc27.x86_64 #1 SMP Wed Jan 3 13:52:28 UTC 2018 x86_64
./spectre-meltdown-checker.sh: line 442: /vmlinuz-4.14.11-300.fc27.x86_64=/boot//vmlinuz-4.14.11-300.fc27.x86_64: No such file or directory

It seems to be a benign error as I get expected results after this message is printed, but it would be nice to fix it. 😃

UNKNOWN (couldn't extract your kernel from /boot/vmlinuz-2.6.18-416.el5PAE)

Hi, could you help me in fix this "UNKNOWN" problem?

Thanks:

Checking vulnerabilities against Linux 2.6.18-416.el5PAE #1 SMP Wed Oct 26 12:06:12 EDT 2016 i686

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Kernel compiled with LFENCE opcode inserted at the proper places: UNKNOWN (couldn't extract your kernel from /boot/vmlinuz-2.6.18-416.el5PAE)

STATUS: UNKNOWN

Misleading text

The script states Kernel compiled with LFENCE opcode inserted at the proper places - while just checking for a threshold quantity.

There is no validation that the extra opcodes are inserted at the proper places

Intel Atom vulnerable?

DId run the script on an Intel Atom 330 / 1.6GHz system, and it is shown vulnerable for all three CVEs. But as per Intel's list at https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr the Atom 330 should not be affected (if I understood correctly).

I guess a check for non-vulnerable Atom processors has not been implemented yet?

Script checks for patches but not initial vulnerability?

So far as I can tell, the script does not actually check that the device's processor is vulnerable. It seems to me that it would be good were it to do that - before it checked for patches.

Spectre Meltdown Checker Automated

Not an Issue, informational.

An Automated Spectre Meltdown downloader and checker. Should work on most Linux Distros.
Something for folks who need an easy way to check their system.

https://github.com/linuxlite/Spectre-Meltdown-Checker-Automated

At the moment -> Rapsberry Pi "false" vulnerability detection

Official statement Raspberry Pi foundation
doesn't reflect the outcome of the tool:
perhaps a check against not vulnerable CPUs from ARM (lscpu) could be added?

Spectre and Meltdown mitigation detection tool v0.19

Checking for vulnerabilities against live running kernel Linux 4.9.46-v7+ #1032 SMP Wed Aug 30 12:09:14 BST 2017 armv7l
Will use no vmlinux image (accuracy might be reduced)
Will use no kconfig (accuracy might be reduced)
Will use System.map file /proc/kallsyms

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: UNKNOWN (couldn't find your kernel image in /boot, if you used neboot, this is normal)

STATUS: UNKNOWN

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: NO
• Mitigation 2
• Kernel compiled with retpoline option: UNKNOWN (couldn't read your kernel configuration)
• 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): NO
• PTI enabled and active: NO

STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)**

AMD vulns

spectre-meltdown-checker/spectre-meltdown-checker.sh

Line 163 in dce917b

variant3=1

Shouldn't this be var1=1, var2=1, and var3=0 for AMD?

Are we sure this works?

Unpatched physical machine on Sandy Bridge CPU and EL7 shows:

STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

All of my EL6 virtual machines on VMware show:

STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

Physical Sandy Bridge CPU and EL6 system shows:

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

Please add new option --version

This is helpful for programs like help2man.
thanks

Meltdown mitigation not detected for Ubuntu (32bits / i386)

Meltdown mitigation detection doesn't work for Ubuntu kernels.
Seems Ubuntu activates PTI with the Kernel option UNWINDER_FRAME_POINTER.

See https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
=> USN 3523-1 (Ubuntu 17.10)
=> https://usn.ubuntu.com/usn/usn-3523-1/
=> Changelog for 4.13.0-25.29 in section 17.10
=> https://launchpad.net/ubuntu/+source/linux/4.13.0-25.29

root@ubuntu-artful:~/spectre-meltdown-checker# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.26

Checking for vulnerabilities against live running kernel Linux 4.13.0-25-generic #29-Ubuntu SMP Mon Jan 8 21:13:33 UTC 2018 i686

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: YES

STATUS: NOT VULNERABLE (808 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: NO
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: 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): NO
• PTI enabled and active: NO

STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

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

Kernel tip introduces cpu/vulnerabilities directory

For kernels that have /sys/devices/system/cpu/vulnerabilities, we'll be 100% sure of the information we have because it'll be exposed by the kernel itself. It will only work in live mode though.

Ubuntu artful still showing vulnerable

I'm uncertain as to whether this is your issue, or Canonical have failed to fix the problem. I've updated to latest kernel, using latest intel-microcode package & verified that initrd was rebuilt.

$ sudo ./spectre-meltdown-checker.sh -v -v
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.13.0-25-generic #29-Ubuntu SMP Mon Jan 8 21:14:41 UTC 2018 x86_64
(debug) found opt_kernel=/boot/vmlinuz-4.13.0-25-generic.efi.signed in /proc/cmdline
(debug) opt_kernel is now /boot/vmlinuz-4.13.0-25-generic.efi.signed
Will use vmlinux image /boot/vmlinuz-4.13.0-25-generic.efi.signed
Will use kconfig /boot/config-4.13.0-25-generic
Will use System.map file /proc/kallsyms
(debug) try_decompress: magic for gunzip found at offset 18357:xy
(debug) try_decompress: decompressed with gunzip successfully!

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 29 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation: (debug) attempted to load module msr, ret=1
 YES 
(debug) attempted to unload module msr, ret=0
*   Kernel support for IBRS: (debug) ibrs: file /sys/kernel/debug/ibrs_enabled doesn't exist
(debug) ibrs: file /sys/kernel/debug/x86/ibrs_enabled doesn't exist
(debug) ibrs: file /proc/sys/kernel/ibrs_enabled doesn't exist
 NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  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): (debug) kpti_support: found option CONFIG_PAGE_TABLE_ISOLATION=y in /boot/config-4.13.0-25-generic
 YES 
* PTI enabled and active: (debug) kpti_enabled: found 'pti' flag in /proc/cpuinfo
 YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

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

im infected

I'm glad I found this Repository. I have had everything unplugged for 5 days now. I'm pretty sure everything in my house is infected including my phone I had a new one.

Now today after much research I still have no idea what is really going on. But earlier I wiped my infected Drive using a fresh USB Ubuntu version USB from a different location and on a different machine I use the gparted and broke the zeros to everything and erased all partitions.

After that I booted up with another fresh USB that never touched the system and installed ubuntu to before it get another wipe.

After finally getting into the system I check my files and see the same directory as before the same one you guys see unable to view them CPU microcode stuff all the Meltdown symptoms. I even saw some bash scripts running before it booted up it took about a minute and a half to get in to the desktop which isn't normal. So basically this thing infected a brand new and saw after I wiped the entire hard drive etcetera so I don't know I guess I need new hardware all around this is ridiculous I haven't been able to work for a week and I have to buy a new computer probably

Spectre V2: add check for cpuinfo "spec_ctrl" ?

I've seen a weird case on a VM:

• Reading from the msr works (the CPU has an updated microcode)
• The kernel has been compiled with ibrs support
• The kernel choose to disable ibrs support
• /proc/cpuinfo does not contain spec_ctrl ibpb_support

I believe this to be a bad qemu package/runtime/configuration, but I was wondering: would it make sense to add a check for the spec_ctrl flag in /proc/cpuinfo?

Please tag version

As you are giving versions to spectre-meltdown-checker.sh, please tag them on github too

$ grep VERSION spectre-meltdown-checker.sh 
VERSION=0.27

Possible false negative on Xen PV DomUs

According to https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/:

Am I affected?

Meltdown is using a design flaw into Intel CPUs only. This is called by Xen sec team "SP3" (aka rogue data cache load). You are impacted only if you are using:

• 64-bits PV type VM (HVM/PVHVM aren't affected!)
• Intel CPUs (AMD chip design is a bit different and not affected)
• untrusted VMs, ie untrusted users having VM access (even non-root!)
• All XenServer versions are affected

64-bits PV guests are vulnerable because guest and hypervisor share the same address space, but with different privileges. HVM aren't.

The checker returns this on a Xen DomU:

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
* Checking if we're running under Xen PV (64 bits):  YES  (Xen PV is not vulnerable)
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

I think Xen PV is not vulnerable is a false negative, am I right ? The test should instead check for Xen HVM / PVHVM DomUs.

Additional flags

It would be useful to add
--color
--global
--no-global

The use case is minimal update making the script default to no-color and no-global exit code
Both may avoid breaking stuff under certain settings

ubeTrick

Atom N270

The script tells that I am vulnerable?

Imposible.

Only /proc/sys/kernel/ibrs_enabled present in Opensuse tumbleweed

I am running Opensuse tumbleweed with kernel 4.14.12-1 (which is patched already), debugfs is mounted under /sys/kernel/debug but there is no such file as /sys/kernel/debug/ibrs_enabled or /sys/kernel/debug/x86/ibrs_enabled. However ibrs_enabled is present here:

/proc/sys/kernel/ibrs_enabled

...and it contains a value of 1.

Not sure if other distros behave the same, just thought I'd let you know.

[cosmetic] --no-sysfs is required for verbosity

The following verbosity is lost without --no-sysfs

* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  NO 
*     The SPEC_CTRL CPUID feature bit is set:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  YES 
*   Kernel compiled with a retpoline-aware compiler:  NO  

* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 

---

Note: Possibly this output is worse verbosity due to naive test of
/sys/kernel/debug/.whatever/   even when /proc/config.gz is showing:

# CONFIG_DEBUG_FS is not set

(edited: earlier reference to: CONFIG_DEBUG_KERNEL was improper)

CoreOS detection "UNKNOWN" due to missing "readelf" utility

Trying to run this command on CoreOS, we get the output:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  UNKNOWN
> STATUS:  UNKNOWN  (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))

The issue being that CoreOS doesn't have a package manager to make it easy to install "readelf".

The "workaround" I found was to use the CoreOS "toolbox" command to install a Fedora container which mounts the host filesystem under /media/root and then run the script in "offline" mode with:

./spectre-meltdown-checker/spectre-meltdown-checker.sh --kernel /media/root/boot/coreos/vmlinuz-a 

NOTE: You have to install readelf with "dnf install binutils" first before running the above command

It would be good if the script checked for CoreOS and then maybe printed out the workaround? Or alternatively used the "toolbox" command to run the diagnostics from the Fedora container (after installing "readelf").

CentOS 6 IBRS compiled in but not enabled?

Output from Centos 6.7 after yum update -y && reboot:

[...]
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES 
*   Kernel support for IBRS:  YES 
 YES 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  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)
[...]

Is this expected, even after the updates are installed?

Thanks

Skyfall and Solace incoming

Hi here,

just a quick note, there are two additional issues incoming: Skyfall and Solace
Still no logos, but I guess this is just a matter of time and this will getting serious. Check out skyfallattack.com.

Cheers, Jan.

AMD - speculative control indicator

Hi,

On AMD processor the processor flag is "ibpb" instead of "spec_ctrl".

•                           if grep ^flags /proc/cpuinfo | grep -qw spec_ctrl; then
  

•                           if grep ^flags /proc/cpuinfo | grep -qw -E "(spec_ctrl|ibpb)"; then
  

root / superuser

Please update doc/disclaimer that root/superuser privileges are required to get accurate results from the script. Normal user results aren't accurate. This is because /sys is checked by the script and owned by root on most (all?) Linuxes.

kernel supports PTI, but how to enable PTI?

I updated my kernel in a debian vm to 3.16.0-5-amd64 and this tool sais:

Spectre and Meltdown mitigation detection tool v0.26

Checking for vulnerabilities against live running kernel Linux 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  UNKNOWN 
> STATUS:  VULNERABLE  (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  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:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Maybe you should add to the readme, how to enable PTI now?

Script reports NOT VULNERABLE even when IBRS is supported partially

I have an example where IBRS is enabled only for Kernel space, but script reports CVE-2017-5715 as not vulnerable. I believe, it should report "partially vulnerable" or something like that in such cases.

Linux Mint 18.3 // ubuntu 16.04 LTS - Why vulnerable to attack 1&2

Hello,

im running linux mint 18.3 which is basically a ubuntu 16.04 Lts with microcode intel-microcode 3.20180108.0~ubuntu16.04.2 update an Kernel: 4.13.0-26-generic (which is patched)
Why am i vulnerable to spectre 1?
only 29 opcodes found, should be >=70 -- Vulnerable
Spectre variante 2: Vulnerable
IBRS hardware + Kernel support OR Kernel with retpoline are needed to mitigate the vulnerability

best regards Razzor

* Checking count of LFENCE opcodes in kernel: UNKNOWN

This seems a bit contradictory to me. Why does it say that the opcodes count is unknown and then reports 33? No error message.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

$ uname -a
Linux blokix 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.26

Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: UNKNOWN

STATUS: VULNERABLE (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

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

• Mitigation 1
• Hardware (CPU microcode) support for mitigation: NO
• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: 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

STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

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

NOTE: I cloned the repo a few minutes before submitting this question.

Specify kernel path in live mode

Hi,

The script seems to look for the kernel in /boot with some specific names, and if you aren't using that you can't do the live mode test.
It would be nice to be able to use --kernel with --live, I'm personally using a pretty simple /boot/kernel-4.14.12 that this script can't find on it's own apparently.

CPU flags "pcid" and "invpcid"

Thanks for your wonderful tool!

In the last days, I performed various performance tests and measured performance degradation due to Meltdown patches in the kernel, especially in virtual machines. The result is, that the degree of performance degradation is dependent on CPU flag "pcid" and probably also on "invpcid". It might be worth to show presence of these CPU flags in your tool.

I posted my results here:

• https://forums.gentoo.org/viewtopic-p-8169200.html#8169200
• https://forums.gentoo.org/viewtopic-p-8169908.html#8169908

Willy Tarreau also saw this dependency on pcid/invpcid in virtual machines:

• https://marc.info/?t=151532047900001&r=1&w=2

A test could be something like this:

for flag in pcid invpcid 
do 
    echo -n "${flag}: "
    if grep -m 1 "^flags" /proc/cpuinfo | grep -q " ${flag}"
    then
        echo "available"
    else
        echo "NOT available"
    fi
done

Add options to pick specific variant to test

I'm running this script now against a cluster. Would it be possible to add a --variant 1,2,3 to pick what to test for? This way I can incrementally see what nodes still need to be patched based on the releases that are happening.

Pine64 board with UNKNOWN status reported as not vulnerable

Dear Speed47,

Bellow if the output of the provided script executed on a Pine64 board running Linux. The CPU is not detected properly. The report show the board as NOT VULNERABLE, but some tests results are UNKNOWN : Can you please confirm if the board/CPU is vulnerable or not ?

jean@owncloud:~/scripts/spectre-meltdown-checker$``
sudo ./spectre-meltdown-checker.sh -v
[sudo] password for jean:
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux 3.10.105-0-pine64-longsleep #3 SMP PREEMPT Sat Mar 11 16:05:53 CET 2017 aarch64
CPU is
Will use no vmlinux image (accuracy might be reduced)
Will use kconfig /proc/config.gz
Will use System.map file /proc/kallsyms
We're missing some kernel info (see -v), accuracy might be reduced
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

• Checking count of LFENCE opcodes in kernel: UNKNOWN

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

• Mitigation 1
• Hardware (CPU microcode) support for mitigation

• The SPEC_CTRL MSR is available:  UNKNOWN  (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
  

• The SPEC_CTRL CPUID feature bit is set:  UNKNOWN  (couldn't read /dev/cpu/0/cpuidr, is cpuid support enabled in your kernel?)
  

• The kernel has set the spec_ctrl flag in cpuinfo:  NO
  

• Kernel support for IBRS: NO
• IBRS enabled for Kernel space: NO
• IBRS enabled for User space: NO
• Mitigation 2
• Kernel compiled with retpoline option: NO
• Kernel compiled with a retpoline-aware compiler: NO

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

• Kernel supports Page Table Isolation (PTI): NO
• PTI enabled and active: NO
• 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)
• Checking if we're running under Xen PV (64 bits): NO

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
A false sense of security is worse than no security at all, see --disclaimer
jean@owncloud:~/scripts/spectre-meltdown-checker$

How can I maybe help regarding the board ?

Many thanks in advance,
Best regards.

raspberry pi falsely reported vulnerable

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
Script output:

Spectre and Meltdown mitigation detection tool v0.19

Checking for vulnerabilities against live running kernel Linux 4.9.67-v7+ #1061 SMP Tue Dec 5 17:17:24 GMT 2017 armv7l
Will use no vmlinux image (accuracy might be reduced)
Will use no kconfig (accuracy might be reduced)
Will use System.map file /proc/kallsyms

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  UNKNOWN  (couldn't find your kernel image in /boot, if you used neboot, this is normal)
> STATUS:  UNKNOWN 

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  UNKNOWN  (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  UNKNOWN  (couldn't read your kernel configuration)
*   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):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)