Remove the kernel mapping in user mode
Requires the running kernel to be built with CONFIG_PAGE_TABLE_ISOLATION=y to mitigate the Meltdown CPU vulnerability by isolating kernel page tables from user mode.
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
Page Table Isolation (PTI/KPTI) is the primary defence against Meltdown (CVE-2017-5754), a CPU side-channel that lets an unprivileged process read arbitrary kernel memory, including passwords, keys and other secrets. PTI keeps the kernel's page tables out of the user-space mapping, so even if the CPU speculatively accesses kernel addresses, they are not present to leak. Without CONFIG_PAGE_TABLE_ISOLATION=y, vulnerable CPUs expose all kernel memory to any local process, which is why this rule is high severity.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r), falling back to /proc/config.gz, so the result reflects the booted kernel. Pavois expects CONFIG_PAGE_TABLE_ISOLATION=y. Note the feature can still be disabled at runtime via the pti=off/nopti boot parameter even when compiled in.
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_PAGE_TABLE_ISOLATION=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_PAGE_TABLE_ISOLATION=y$/) }
endHow to verify it is applied
Build-time: grep '^CONFIG_PAGE_TABLE_ISOLATION=' /boot/config-$(uname -r) → CONFIG_PAGE_TABLE_ISOLATION=y. Runtime status: cat /sys/devices/system/cpu/vulnerabilities/meltdown should report Mitigation: PTI, and dmesg | grep -i 'page table isolation' should show it enabled.
Inspect & investigate
Runtime mitigation state is in /sys/devices/system/cpu/vulnerabilities/meltdown. Boot messages: dmesg | grep -i 'page table isolation' (e.g. Kernel/User page tables isolation: enabled). Check cat /proc/cmdline for an overriding nopti/pti=off.
Remediation
No automated remediation: CONFIG_PAGE_TABLE_ISOLATION is a kernel build-time option, enabled in all current distribution kernels. It cannot be turned on at runtime. If the running kernel reports PTI disabled, check the kernel command line for nopti/pti=off and remove it (a separate cmdline/GRUB change), then reboot. Apply manually; pavois harden apply cannot change a compiled-in setting.
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 PTI is absent or disabled, any local user (including a container or a script) can read kernel memory via Meltdown and steal credentials, a severe, fully practical attack on affected Intel CPUs. The trade-off is performance: PTI adds overhead to system calls and context switches (a few percent, more on syscall-heavy workloads). Precaution: never disable PTI on vulnerable hardware to chase performance; if you must benchmark the cost, do it on isolated, non-sensitive hosts. There is no lockout risk, it is transparent to applications.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R25 | 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.