Limit CPU consumption of the Perf system
Sets kernel.perf_cpu_time_max_percent = 1 to cap the CPU time the Perf subsystem may consume, protecting system availability.
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
kernel.perf_cpu_time_max_percent caps the maximum percentage of CPU time that the kernel Perf subsystem may consume handling performance events. Leaving Perf unbounded lets a high (or maliciously crafted) sampling load monopolise CPU and degrade or deny service. Restricting Perf to 1% decreases the risk of availability problems caused by runaway profiling activity.
What Pavois checks
Pavois reads the live kernel value with kernel_parameter('kernel.perf_cpu_time_max_percent') (equivalent to sysctl kernel.perf_cpu_time_max_percent), not a /etc/sysctl.d/*.conf line. A file may declare 1 while the running kernel keeps a different value because a drop-in overrode it or the file was never applied. The effective parameter is the only authoritative proof.
describe kernel_parameter('kernel.perf_cpu_time_max_percent') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.perf_cpu_time_max_percent[[:space:]]*=[[:space:]]*1([[: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 kernel.perf_cpu_time_max_percent. Expected output:
kernel.perf_cpu_time_max_percent = 1
Inspect & investigate
No dedicated log line. Confirm with sysctl kernel.perf_cpu_time_max_percent. When Perf throttles itself because handling exceeded the limit, the kernel emits a warning in dmesg/journalctl -k such as perf: interrupt took too long ... lowering kernel.perf_event_max_sample_rate.
Remediation
Pavois's harden plan uses the sysctl resource to set kernel.perf_cpu_time_max_percent = 1, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.perf_cpu_time_max_percent |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: an unbounded Perf workload (intentional or not) can consume excessive CPU, degrading or denying service.
Precautions before applying:
- This is a profiling/observability trade-off. Capping Perf at 1% means heavy, legitimate
perfruns will be throttled and the kernel may automatically lower the sampling rate, reducing profiling accuracy. On dedicated performance-analysis hosts you may need to relax this. - No application breakage or lockout risk; the change is fully reversible at runtime.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | 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.