| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Fix ARM CPU display name, and properly
detect known vulnerable ARM CPUs when
multiple different model cores are
present (mostly Android phones)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is now handled properly by checking the CPU
vendor, family, model instead of looking for the
commercial name of the CPU in /proc/cpuinfo
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of just counting the number of LFENCE
instructions, now we're only counting the those
that directly follow a jump instruction.
|
| |
|
|
|
|
| |
449: ./spectre-meltdown-checker.sh: 3: parameter not set
This happened only on blacklisted microcodes, fixed by
adding set +u before the return
|
| | |
|
| |
|
|
|
|
| |
Add a paragraph in the disclaimer stating that this tool focuses
on the kernel side of things, and that for Spectre, any software
might be vulnerable.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Now `shellcheck -s sh` no longer shows any warnings.
This should improve compatibility with exotic shells
as long as they're POSIX compliant.
|
| |
|
|
|
|
|
|
| |
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)"
|
| | |
|
| |
|
|
|
|
| |
When the arch_capabilities MSR is not there, it means
that all the features it might advertise can be considered
as NO instead of UNKNOWN
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
For detection of IBRS_ALL and RDCL_NO, fallback to
UNKNOWN when we were unable to read the CPUID or MSR.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
On some kernels there could be IBRS support but not
IBPB support, in that case, don't report VULN just
because IBPB is not enabled when IBRS is
|
| | |
|
| |
|
|
|
|
| |
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 we would just check if retpoline was compiled
in, now we also check that it's enabled at runtime
(only in live mode)
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Pentium E series are not in the vulnerable list from
Intel, and Spectre2 PoC reportedly doesn't work on
an E5200
|
| |
|
|
|
|
|
| |
in text-mode 80-cols TERM=linux terminals, colors
were not displaying properly, one had to use
--no-color to be able to read some parts of the
text.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
