Avoid speculative indirect branches in kernel
Requires the kernel to be built with CONFIG_RETPOLINE=y so indirect branches use retpoline thunks that mitigate Spectre v2.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
This is required to enable protection against Spectre v2 (branch target injection, CVE-2017-5715). CONFIG_RETPOLINE builds the kernel with retpoline thunks that replace vulnerable indirect branches with a construct the CPU cannot mis-speculate, denying an attacker the ability to steer speculative execution toward a gadget and leak kernel memory (passwords, keys) across privilege boundaries.
What Pavois checks
Pavois reads the build options of the running kernel, grep '^CONFIG_RETPOLINE=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires y. Reading the live kernel's own config (keyed on uname -r) reflects exactly the booted kernel, including vendor builds, which a package-name guess or generic file cannot.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_RETPOLINE=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_RETPOLINE=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_RETPOLINE=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_RETPOLINE). Expected output:
CONFIG_RETPOLINE=y
Confirm the live mitigation status with cat /sys/devices/system/cpu/vulnerabilities/spectre_v2, it should mention Retpolines and not say Vulnerable.
Inspect & investigate
No routine log entry. The runtime mitigation is announced at boot in dmesg / journalctl -k (lines mentioning Spectre V2 : Mitigation: Retpolines). The build flag is confirmed with grep CONFIG_RETPOLINE /boot/config-$(uname -r) and live state with /sys/devices/system/cpu/vulnerabilities/spectre_v2.
Remediation
This is a kernel build-time option, so Pavois ships no automated harden step for it. It is satisfied by booting a distribution kernel compiled with CONFIG_RETPOLINE=y (the case for all current Debian/Ubuntu/RHEL kernels). Ensure the boot line does not force spectre_v2=off or nospectre_v2; a custom kernel must be rebuilt.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If absent, the host is exposed to Spectre v2 cross-privilege memory disclosure. Precautions: retpoline (and any companion IBRS/IBPB use) carries a modest CPU performance cost on branch-heavy workloads; this is the accepted trade-off for the mitigation. Do not disable it with spectre_v2=off on shared or multi-tenant systems. Enabling it only requires booting a compliant kernel, test a reboot on a non-production host if you also change microcode.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R15 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.