This patch adds 0x43 check for cavium implementor id in function
parse_cpu_details. Also adds that Cavium Soc is not vulnerable to variant 3/3a
Signed-off-by: Manish Jaggi <manish.jagg@cavium.com>
* variant4 from common.c::cpu_no_spec_store_bypass
Variant 4 - Add function to 'whitelist' the hand-full of CPUs unaffected by speculative store bypass.
This would allow improved determination of variant 4 status ( #189 ) of immune CPUs while waiting for the 4.17/stable patches to be backported to distro kernels.
Source of cpu list : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/common.c#n945)
Modeled after is_cpu_specex_free()
* amd families fix
amd families are reported by parse_cpu_details() in decimal
* remove duplicates
Only list processors which speculate and are immune to variant 4.
Avoids duplication with non-speculating CPUs listed in is_cpu_specex_free()
* ibrs can't be enabled on no ibrs cpu
If the cpu is identified, and does not support SPEC_CTRL or IBRS, then ibrs can't be enabled, even if supported by the kernel.
Instead of reporting IBRS enabled and active UNKNOWN, report IBRS enabled and active NO.
This adds a check before loading the cpuid and msr modules under linux, ensuring they are not unloaded in exit_cleanup() if they were initially present.
This test worked for some early versions of the retpoline
implementation in vanilla kernels, but the corresponding
flag has been removed from /proc/cpuinfo in latest kernels.
The full information is available in /sys instead, which
was already implemented in the script.
Based on a kernel patch that has been merged to Linus' tree.
Some of the detections we did by grepping the model name
will probably no longer be needed.
Implement detection of mitigation for Variant 1 that is
being pushed on vanilla kernel.
Current name of the patch:
"spectre variant1 mitigations for tip/x86/pti" (v6)
Also detect some distros that already backported this
patch without modifying the vulnerabilities sysfs hierarchy.
This detection is more reliable than the LFENCE one, trust
it and skip the LFENCE heuristic if a match is found.
The values used should be the ones that come from cpuinfo instead of
the test values. The following line will print the last tuple tested
instead of the actual values of the CPU.
Line 689: _debug "is_ucode_blacklisted: no ($model/$stepping/$ucode)"
Some Intel microcodes are known to cause instabilities
such as random reboots. Intel advises to revert to a
previous version if a newer one that fixes those issues
is not available. Detect such known bad microcodes.
In batch mode, $echo_cmd was not initialized early
enough, and caused this error:
./spectre-meltdown-checker.sh: 899: ./spectre-meltdown-checker.sh: -ne: not found
Fix it by initing echo_cmd unconditionally at the start
Move all the CPU checks to their own section,
for clarity. We now check for IBRS, IBPB, STIBP,
RDCL_NO and IBRS_ALL. We also show whether the
system CPU is vulnerable to the three variants,
regardless of the fact that mitigations are in
place or not, which is determined in each vuln-
specific section.
For variant3 under AMD, the debugfs vulnerabilities hierarchy
flags the system as Vulnerable, which is wrong. Trust our own
is_cpu_vulnerable() func in that case
When kernel is not compiled with retpoline option, doesn't
have the sysfs vulnerability hierarchy and our heuristic to
detect a retpoline-aware compiler didn't match, change result
for retpoline-aware compiler detection from UNKNOWN to NO.
When CONFIG_RETPOLINE is not set, a retpoline-aware compiler
won't produce different asm than a standard one anyway.
Before, when the /sys kernel vulnerability interface
was available, we would bypass all our tests and just
print the output of the vulnerability interface. Now,
we still rely on it when available, but we run our
checks anyway, except for variant 1 where the current
method of mitigation detection doesn't add much value
to the bare /sys check
In addition to IBRS (and microcode support), IBPB
must be used to mitigate variant 2, if retpoline
support is not available. The vulnerability status
of a system will be defined as "non vulnerable"
if IBRS and IBPB are both enabled, or if IBPB
is enabled with a value of 2 for RedHat kernels,
see https://access.redhat.com/articles/3311301
In offline mode, in the worst case where an invalid
config file is given, and we have no vmlinux image
nor System.map, the script was reporting Variant 2
and Variant 3 as vulnerable in the global status.
Replace this by a proper pair of UNKNOWNs
To avoid false negatives when looking for a message
in dmesg, we were previously also grepping in known
on-disk archives of dmesg (dmesg.log, kern.log).
This in turn caused false positives because we have no
guarantee that we're grepping the dmesg of the current
running kernel. Hence we now only look in the live
`dmesg`, detect if it has been truncated, and report
it to the user.
* Add special CoreOS compatibility mode
* CoreOS: refuse --coreos if we're not under CoreOS
* CoreOS: warn if launched without --coreos option
* is_coreos: make stderr silent
* CoreOS: tiny adjustments
* correct is_cpu_vulnerable() comment
As far as I can tell, the function and usage are correct for the comment
to be inverted.
Add a clarifying note as to why the value choice makes sense.
* exit on invalid varient
If this happens, it's a bug in the script. None of the calling code
checks for status 255, so don't let a scripting bug cause a false
negative.
* no need to set vulnerable CPUs
According to comment above this code:
'by default, everything is vulnerable, we work in a "whitelist" logic here.'
We were saying unknown instead of vulnerable when the count of lfence opcodes was low
This was not impacting batch mode or the final decision, just the human-readable output of the script.
With --batch json there must not be any other output on stdout, so redirect warnings to stderr will show the warning on the console and only the json output is on stdout.
In case of a busy or misconfigured server, kernel message buffer loop
can be filled with messages broadcasted later than boot time. So dmesg
command wont return boot time messages.
Grepping /var/log/dmesg fixes it and this log file location semms pretty
standard across many common distros
Rewrite the way the output is processed:
- Define verbosity level (currently warn, info (default) & verbose)
- Add a batch mode, for simple machine parsing
- Isolate file check to different elif (allowing to add more)
- Do the PTI debugfs check first (faster and supposed to be dynamic)
- If pti_enable is 0, don't trust dmesg (supposed to be dynamic)
Small issue with the USER environment variable:
$ echo $USER
thib
$ sudo sh -c 'echo $USER'
thib
$ sudo -i sh -c 'echo $USER'
root
Rather than recommending users to use sudo --login / -i, use the (very
widespread/portable) id program to retrieve the effective user ID
instead and don't change the recommendation.
$ id -u
1000
$ sudo id -u
0
$ sudo -i id -u
0
2018-01-08 01:22:14 +01:00
3 changed files with 3217 additions and 237 deletions
- other architectures will work, but mitigations (if they exist) might not always be detected
For Linux systems, the script 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.
For BSD systems, the detection will work as long as the BSD you're using supports `cpuctl` and `linprocfs` (this is not the case of OpenBSD for example).
## Easy way to run the script
- Get the latest version of the script using `curl`*or*`wget`
- 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)
**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
Example of the output of the script:
**CVE-2018-3640** rogue system register read (Variant 3a)
- Impact: TBC
- Mitigation: microcode update only
- Performance impact of the mitigation: negligible
```
$ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.07
**CVE-2018-3639** speculative store bypass (Variant 4)
* 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)
## Understanding what this script does and doesn't
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)
```
This tool does its best to determine whether your system is immune (or has proper mitigations in place) for the collectively named "speculative execution" vulnerabilities. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying whether your system has the known correct mitigations in place.
However, some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels).
Your system exposure also depends on your CPU. As of now, AMD and ARM processors are marked as immune to some or all of these vulnerabilities (except some specific ARM models). All Intel processors manufactured since circa 1995 are thought to be vulnerable, except some specific/old models, such as some early Atoms. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
The nature of the discovered vulnerabilities being quite new, the landscape of vulnerable processors can be expected to change over time, which is why this script makes the assumption that all CPUs are vulnerable, except if the manufacturer explicitly stated otherwise in a verifiable public announcement.
Please also note that for Spectre vulnerabilities, all software can possibly be exploited, this tool only verifies that the kernel (which is the core of the system) you're using has the proper protections in place. Verifying all the other software is out of the scope of this tool. As a general measure, ensure you always have the most up to date stable versions of all the software you use, especially for those who are exposed to the world, such as network daemons and browsers.
This tool has been released in the hope that it'll be useful, but don't use it to jump to conclusions about your security.
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
