When checking for CVE-2017-5715 (i.e. `check_CVE_2017_5715_linux()`),
if we can't inspect (with `readelf`) or decompress the Linux kernel
image, then we report there is no kernel image (i.e. `we need the
kernel image` or `kernel image missing`, respectively), which confuses
users when the associated file exists.
Instead use `kernel_err` to provide a correct and detailed description
of the problem (e.g. `missing '...' tool, please install it, usually
it's in the '...' package`), so the user can take the prescribed
action.
* fix --help message
Commit 7b72c20f89 added help text for the
--cve switch, and the "can be specified multiple times" note got
associated with the --cve switch instead of staying with the --variant
switch. Restore the line to belong to the --variant switch help
message.
* Add new variants to error message
Commit 8e870db4f5 added new variants but
did not add them to the error message that listed the allowable
variants. Add them now.
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.
