This change ensures we check for SMT and advise the user to disable it for maximum security.
Doing this, we'll help users mitigate a whole range of vulnerabilities taking advantage of SMT to attack purely from userland other userland processes, as seen in CVE-2018-5407 (also see #261)
On a (pre-SkyLake) system, where /sys/.../vulnerabilities/spectre_v2 is
"Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling"
the tool, incorrectly, reports, a couple of lines above:
* IBRS enabled and active: YES (for kernel and firmware code)
Use '\<IBRS\>', as suggested by @jirislaby, in upstream issue #275
(https://github.com/speed47/spectre-meltdown-checker/issues/275) when
checking whether IBRS is enabled/active for the kernel.
With that, the output becomes:
* IBRS enabled and active: YES (for firmware code only)
which is actually the case.
I double checked that, if the same kernel is used on a post-SkyLake
hardware, which on openSUSE uses IBRS as, even with this change, the
tool (this time correctly) reports:
* IBRS enabled and active: YES (for kernel and firmware code)
As we read sysctl values under the vmm hierarchy, the modules needs to be loaded,
so if not already done, we load it before testing for CVE-2018-3620 and CVE-2018-3646
currently, the script tries to use the wrong kernel image on Arch if an
alternative kernel (hardened, zen, or lts) is in use. Fortunately, all
the Arch kernel packages place a symlink to the kernel image as /usr/lib/modules/$(uname -r)/vmlinuz, so simply removing the guess for Arch fixes the issue.
Missing kernel information can cause all sorts of false positives or
negatives. This is worth at least a warning, and repeating immediately
following the status.
As it's seen in unmap_kernel_at_el0 (both the function definition
and its usage in arm64_features[]) from arch/arm64/kernel/cpufeature.c
the kernel reports this string:
CPU features: detected: Kernel page table isolation (KPTI)
or (before commit e0f6429dc1c0 ("arm64: cpufeature: Remove redundant "feature"
in reports")):
CPU features: detected feature: Kernel page table isolation (KPTI)
if KPTI is enabled on the system.
So on let's adjust check_variant3_linux() to make it grep these
strings if executed on an aarch64 platform.
Tested on a Cavium ThunderX2 machine.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Use platomav's MCExtractor DB as the reference to decide whether our CPU microcode is the latest or not.
We have a builtin version of the DB in the script, but an updated version can be fetched and stored locally with --update-mcedb
* Add another location of Arch Linux ARM kernel
* Fix detection of CVE-2018-3615
We change the value of variantl1tf in the line directly before so its
value will never be "immune". Instead we can directly use the value of
variantl1tf to initialize variantl1tf_sgx.
* Fix cases where a CPU ucode version is not found in $procfs/cpuinfo.
When running whithin a virtual machine, it seems like $procfs/cpuinfo doesn't contain
a 'microcode' line, which triggers a script runtime error.
Fall back to '0x0' in this case, as other part of the script seems to already this
as a default value anyway.
* Double quote to prevent globbing and word splitting.
Commit b48b2177b7 ("feat: Add Clear Linux Distro (#244)") broke kernel
detection for distros using that directory for other purposes than
storing the kernel image.
Example:
# pacman -Qo /lib/kernel
/usr/lib/kernel/ is owned by mkinitcpio 24-2
/usr/lib/kernel/ is owned by systemd 239.2-1
Signed-off-by: Laszlo Toth <laszlth@gmail.com>
When using this script on a large amount a machine (via clustershell or
instance) it can be easier to have a very short result on one line
showing only the vulnerabilities
The spectre-meltdown-checker.sh file is missing licensing information.
The SPDX identifier is a legally binding shorthand, which can be
used instead of the full boiler plate text.
* Listed the required volumes in the Dockerfile.
* Added docker-compose.yml for convenience as users won't need to manually
specify volumes and stuff when running through docker-compose.
Adjusted README.md to reflect this change.
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)"
- CVE-2018-12126 [microarchitectural store buffer data sampling (MSBDS)] aka 'Fallout'
- CVE-2018-12130 [microarchitectural fill buffer data sampling (MFBDS)] aka 'ZombieLoad'
- CVE-2018-12127 [microarchitectural load port data sampling (MLPDS)] aka 'RIDL'
- CVE-2019-11091 [microarchitectural data sampling uncacheable memory (MDSUM)] aka 'RIDL'
Without options, it'll inspect your currently running kernel.
You can also specify a kernel image on the command line, if you'd like to inspect a kernel you're not running.
Supported operating systems:
- Linux (all versions, flavors and distros)
- BSD (FreeBSD, NetBSD, DragonFlyBSD)
The script will do its best to detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number.
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
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`
- 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: TBC
## Understanding what this script does and doesn't
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. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
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.
