Harden the operation of the BPF just-in-time compiler
Sets net.core.bpf_jit_harden=2 to blind constants and hide addresses in JIT-compiled BPF code for all users.
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
The eBPF just-in-time (JIT) compiler turns BPF bytecode into native machine code for speed, but that generated code lives in kernel space and its addresses can leak via /proc/kallsyms. Attackers have abused the JIT to build JIT-spraying primitives and to defeat kernel ASLR, turning a BPF program into a stepping stone for kernel exploitation. Setting net.core.bpf_jit_harden=2 enables hardening for all users (not just unprivileged ones): it randomizes/blinds constants in the emitted code and stops exposing JIT addresses, removing these exploitation aids.
What Pavois checks
Pavois reads the running kernel value via kernel_parameter('net.core.bpf_jit_harden') and asserts it equals 2. The effective value is what governs how the JIT actually emits code right now; a key written in /etc/sysctl.d/ but not reloaded, or shadowed by another drop-in, would leave the kernel at its default. Only reading the live value (not the config files) proves the hardening is truly in force.
describe kernel_parameter('net.core.bpf_jit_harden') do
its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*net.core.bpf_jit_harden[[:space:]]*=[[:space:]]*2([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl net.core.bpf_jit_harden. Expected output:
net.core.bpf_jit_harden = 2
Inspect & investigate
sysctl net.core.bpf_jit_hardenshows the current value.cat /proc/sys/net/core/bpf_jit_hardenis the raw kernel value.- This parameter produces no per-event log; it only changes how the JIT emits code. To audit BPF usage itself, inspect loaded programs with
bpftool prog show(requires root).
Remediation
Pavois's harden plan uses the sysctl resource to set net.core.bpf_jit_harden to 2. It writes the key into a Pavois-managed drop-in and reloads it so the JIT hardening is active immediately and survives reboots. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | net.core.bpf_jit_harden |
|---|---|
| resource | sysctl |
| value | 2 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Constant blinding adds CPU overhead to JIT-compiled BPF programs, so workloads that lean heavily on eBPF in the hot path (high-rate XDP/tc traffic filtering, certain observability tracers like Cilium or heavy bpftrace use) may see measurably reduced BPF throughput. There is no risk of network or service lockout, this is a pure performance/security trade-off. Before applying on a BPF-intensive datapath, benchmark the impact; if it is unacceptable, value 1 (hardens only unprivileged programs) is a lighter alternative, though 2 is what the benchmarks require.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R12 | direct | 2.0 | high |
| NIST | CM-6, SC-7(10) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.