* 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
- 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:
## Disclaimer
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).
```
$ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.02
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. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
* Kernel compiled with LFENCE opcode inserted at the proper places: NO (only 38 opcodes found, should be >= 60)
> STATUS: VULNERABLE
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.
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.
