← All rules
SOCLE-CLD-KRN-016// Kernel command linemediumeffective runtime

Configure Speculative Store Bypass Mitigation

Enforces the kernel parameter spec_store_bypass_disable=on to enable the Speculative Store Bypass (SSB) CPU mitigation system-wide.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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

On vulnerable processors, a speculatively forwarded store can be exploited through a cache side-channel attack. This allows an attacker to read memory they should not be able to reach directly, for example, leaking secrets from inside sandboxed or JIT-compiled code (Spectre variant 4 / CVE-2018-3639). Forcing spec_store_bypass_disable=on enables the kernel mitigation system-wide instead of leaving it to per-process opt-in.

What Pavois checks

Pavois reads the effective boot command line from /proc/cmdline, which reflects the kernel arguments the running system was actually started with. This beats grepping /etc/default/grub or grub.cfg: those may be edited but not regenerated, may be overridden by drop-ins under /etc/default/grub.d/, or may differ from what the bootloader truly passed. Only /proc/cmdline proves the mitigation is live on the current boot.

describe command('cat /proc/cmdline') do
  its('stdout') { should match(/(^| )spec_store_bypass_disable=on( |$)/) }
end
describe command("grep -hwsF 'spec_store_bypass_disable=on' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

How to verify it is applied

Run cat /proc/cmdline and confirm it contains spec_store_bypass_disable=on. You can also check the resolved CPU state with cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass, which should report mitigation as active rather than Vulnerable.

Inspect & investigate

Inspect the kernel ring buffer with dmesg | grep -i 'speculative store bypass' or journalctl -k | grep -i ssb to see how the kernel reports the mitigation at boot. The live status is exposed via the sysfs entry /sys/devices/system/cpu/vulnerabilities/spec_store_bypass.

Remediation

Pavois's harden plan uses the kernel_cmdline resource to add spec_store_bypass_disable=on to the bootloader configuration and regenerate it. Because it is a boot-time parameter, reboot_required is true, the change only takes effect after the next reboot. Apply it with pavois harden apply.

Pavois applies this with its own harden engine, the plan below, not a shell script:

paramspec_store_bypass_disable=on
reboot_requiredtrue
resourcekernel_cmdline
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Without this mitigation the host stays exposed to Speculative Store Bypass attacks that can leak in-process secrets. Enabling it has a measurable but usually modest performance cost on memory-bound workloads, and it requires a reboot to take effect. Precautions: schedule the reboot during a maintenance window, verify the bootloader regenerated correctly before rebooting (grep spec_store_bypass /boot/grub*/grub.cfg or grubby --info=ALL on RHEL), and keep console/IPMI access in case the new command line prevents a clean boot.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R8direct2.0high

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.

Sources & references