← All rules
SOCLE-CLD-KRN-020// Kernel buildmediumeffective runtime

Emulate Privileged Access Never (PAN)

Ensures the ARM64 kernel is built with CONFIG_ARM64_SW_TTBR0_PAN=y, providing software emulation of Privileged Access Never (PAN) on CPUs without hardware PAN.

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

Privileged Access Never (PAN) is the ARM equivalent of x86 SMAP: it stops the kernel from accidentally (or maliciously, via an exploit) dereferencing user-space addresses while running in privileged mode. On ARM64 hardware that lacks the hardware PAN feature, CONFIG_ARM64_SW_TTBR0_PAN=y emulates it in software by switching TTBR0. Without it, classic exploit techniques like ret2usr, placing attacker-controlled code/data in user memory and tricking the kernel into using it, become viable, turning a kernel bug into full compromise.

What Pavois checks

Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r) (fallback /proc/config.gz) and asserts CONFIG_ARM64_SW_TTBR0_PAN=y. Reading the live kernel's effective config, keyed on uname -r, is more reliable than guessing from a /boot/config-* file, because it matches the exact image GRUB booted even when several kernels coexist. This option only applies on ARM64; on x86 systems the line is simply absent (the equivalent protection is SMAP).

only_if('arm64 only') { os.arch.to_s =~ /aarch64|arm/ }
describe command("grep -h '^CONFIG_ARM64_SW_TTBR0_PAN=' /boot/config-$(uname -r) 2>/dev/null; zcat /proc/config.gz 2>/dev/null | grep '^CONFIG_ARM64_SW_TTBR0_PAN='") do
  its('stdout') { should match(/^CONFIG_ARM64_SW_TTBR0_PAN=y$/) }
end

How to verify it is applied

Run grep -h '^CONFIG_ARM64_SW_TTBR0_PAN=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep ARM64_SW_TTBR0_PAN). Expected on ARM64: CONFIG_ARM64_SW_TTBR0_PAN=y. Confirm the arch with uname -m (should report aarch64).

Inspect & investigate

This is a static kernel build option with no runtime log. Inspect it with zcat /proc/config.gz | grep ARM64_SW_TTBR0_PAN or grep ARM64_SW_TTBR0_PAN /boot/config-$(uname -r). On boot, dmesg | grep -i pan may indicate PAN support on the CPU.

Remediation

No automated remediation is shipped: this is a kernel compile-time option. Apply it by booting an ARM64 kernel built with CONFIG_ARM64_SW_TTBR0_PAN=y, most distribution kernels already enable it, otherwise rebuild the kernel. pavois harden apply cannot change it.

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

resourcekernel_build
pavois harden plan local

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

Impact & precautions

Risk if absent: on ARM64 CPUs without hardware PAN, the kernel can be tricked into reading/executing user-space memory, enabling ret2usr-style privilege escalation from an otherwise limited kernel bug.

Precautions before changing it: the option is only meaningful on ARM64; ignore the finding on x86. Software TTBR0 PAN adds a small per-syscall overhead but no functional risk. Changing kernels requires a reboot, keep the previous kernel entry in GRUB as a fallback and validate boot on a console before decommissioning the old image.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R27direct2.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

Official standards

ANSSI-BP-028 (2.0) ↗