Skip to content

Node kernel requirements for strict enforcement

Candidate behavior — not yet released

This page describes the v0.13.169 agent candidate and the next CLI kernel checklist. Neither is a published release receipt. Use the component versions and the matched, signed release's installation procedure for deployment. Earlier CLI builds do not provide the complete checklist or strict kernel verdict described here.

Strict enforcement requires BPF LSM and a synchronous deny path for every required policy vector on the actual node. A distro name, kernel version, successful feature probe, native syscall denial or full LSM attachment count does not establish complete coverage. The candidate refuses incomplete or unproven coverage and retains existing enforcement. Keep current protection running while qualifying a replacement.

Required node facilities

Use cloudtaser-cli assess --verbose with the next CLI to inspect every item below. The evidence workflow supplies host observations and the exact candidate's measured qualification; Kubernetes metadata alone cannot read most of these facilities.

Kernel and distro. Identify the running release and build; vendor backports can change eligibility. Read /proc/sys/kernel/osrelease and /etc/os-release. Next CLI checklist fields: kernel_version, distro.

BPF LSM. Build with CONFIG_BPF_LSM=y and activate bpf in the LSM stack. If boot configuration omits it, preserve the node's existing LSMs and add bpf to lsm=, then reboot. /sys/kernel/security/lsm must contain the exact member bpf; config and boot intent alone do not prove activation. Next CLI checklist fields: CONFIG_BPF_LSM, active_lsm, lsm_boot.

securityfs. Mount securityfs, normally at /sys/kernel/security, and expose the host mount to the agent. A hidden or unreadable LSM list stays UNKNOWN. Next CLI checklist fields: securityfs.

Kernel BTF. Use CONFIG_DEBUG_INFO_BTF=y and expose /sys/kernel/btf/vmlinux. A valid BTF header proves presence, not all required types, CO-RE relocations or attachments. Next CLI checklist fields: btf.

Synchronous syscall denial. Provide modifiable targets through function error injection or the native prefix rule below, or another candidate-supported measured deny mechanism for each required vector. Next CLI checklist fields: CONFIG_FUNCTION_ERROR_INJECTION, CONFIG_BPF_KPROBE_OVERRIDE, fmod_ret.

IA32 on x86-64. Disable the ABI with effective proof or qualify every required compat deny path. An installed 64-bit userspace does not disable int 0x80. Next CLI checklist fields: CONFIG_IA32_EMULATION, ia32_boot, ia32_entry.

Separate x32 ABI. Inspect CONFIG_X86_X32_ABI (CONFIG_X86_X32 in older kernels) and CONFIG_X86_X32_DISABLED. The latter defaults x32 off when enabled, but syscall.x32 can override that default. The next CLI records the filtered boot option and inspects /sys/module/syscall/parameters/x32 together with config and boot evidence for the effective entry state. IA32 disablement does not disable or qualify x32; see the limitation below. Next CLI checklist fields: CONFIG_X86_X32, CONFIG_X86_X32_DISABLED, x32_boot, x32_entry.

Perf access. Read the actual kernel.perf_event_paranoid value and verify the candidate's BPF/PERFMON capabilities and real attach results. It is not a numeric pass threshold. Next CLI checklist fields: kernel.perf_event_paranoid.

Tracing filesystems. Expose host tracefs and the required tracepoints. Inspect mountinfo for both filesystems; debugfs is optional when tracefs is accessible. Next CLI checklist fields: tracefs, debugfs.

The helper reads configuration from running /proc/config.gz, falling back to /boot/config-<exact-running-release>. Use configuration from the actual running kernel build; its filename does not authenticate it. Mount observations come from /proc/self/mountinfo in the host namespaces. Only lsm=, ia32_emulation= and syscall.x32 are retained from the boot command line, not the full line. See the kernel's LSM BPF documentation and boot parameter reference.

Function error injection and the Linux 7.1 native prefix rule

On older kernels, CONFIG_FUNCTION_ERROR_INJECTION=y supplies the function error injection allowlist used by fmod_ret. Each target must still be modifiable and pass actual load and attachment. An available override-return helper also requires the applicable kernel support and successful blocking attachments; a config flag alone is insufficient. Tracepoints and ordinary fentry observation cannot replace synchronous denial.

With FEI=n, upstream Linux 7.1+ permits fmod_ret on architecture-native syscall prefixes. On an x86-64 kernel this means __x64_, and does not cover IA32 __ia32_ targets. With FEI enabled, the error injection allowlist still controls each target; version 7.1 does not waive that requirement. Native ARM64 uses __arm64_ separately, and x86 ABI checks are not applicable on ARM64. These eligibility rules still require measured qualification, including on vendor kernels with backports. See the Linux 7.1 verifier.

IA32 emulation: disable it effectively or prove compat denial

On x86-64, a 64-bit process can execute IA32 syscalls through int 0x80. Removing 32-bit executables and libraries does not remove this entry path. Native enforcement and LSM hooks do not cover every compat policy check. Choose one of these paths, then rerun all native and LSM qualification too:

  • Use a kernel built with CONFIG_IA32_EMULATION=n.
  • On Linux 6.7+ with CONFIG_IA32_EMULATION=y, boot with ia32_emulation=0, reboot and verify effective disablement with the candidate's probe. Check vendor implementation/backports for the exact build.
  • Keep IA32 enabled only where every required compat deny program actually loads, attaches and retains the required runtime proof.

Kernels older than 6.7 do not implement the upstream parameter. When compat denial is unavailable, retaining one of those older kernel series requires a custom-built kernel without CONFIG_IA32_EMULATION, together with every other required facility. A replacement kernel must also meet the agent's minimum BPF requirements. Alternatively, move to a suitable newer kernel and prove ABI disablement or complete compat denial there. An ignored boot option does not remove coverage requirements.

The candidate agent and next CLI use a bounded native ELF64 child that executes harmless IA32 getpid through int 0x80. Only termination by SIGSEGV proves boot-disabled IA32. A return, syscall error, ordinary exit, SIGSYS or another signal, setup/exec/wait failure or timeout does not prove disablement. The child uses a sealed anonymous memfd, disables core dumps and has a two-second deadline. Execution restrictions such as non-executable memfds can prevent proof and keep qualification closed. A boot option or default-disabled config alone is intent. The kernel's boot gate is described in the IA32 entry source and parameter documentation.

Inventory 32-bit workloads before removing their ABI. Disabling IA32 does not repair native denial failures. The separate x32 ABI remains a known coverage limitation: this candidate's strict verdict does not certify x32 coverage. IA32 proof cannot waive it. A future seccomp ABI gate is not implemented and cannot be used as a workaround for this candidate.

Perf policy and attachment errors

kernel.perf_event_paranoid is informational in the checklist. PASS means the value was read, not that the agent can attach. The recorded Debian 6.12 and 7.2 diagnostics used value 2 and attached their LSM and tracepoint programs; strict refusal came from deny-vector gaps. Do not lower this sysctl merely because it is positive. Check effective BPF/PERFMON capabilities, filesystem visibility, kernel security policy and the exact verifier/attachment error. An attach failure is not proof that perf policy caused it. The candidate also repairs the fork tracepoint's dynamic PID layout through CO-RE; increasing privileges does not repair a stale layout. See Linux perf access control.

Stock distribution expectations and live evidence

This table concerns x86-64 kernel requirements for the candidate. Apply the common LSM, securityfs, BTF, tracing and capability checklist to every row. Kernel flavors, updates and vendor backports differ; inspect the running build. “Expected” means an inference from the named series and reviewed candidate requirements, not a live strict pass or a distribution-wide qualification.

Distribution Stock kernel series What it needs for candidate strict enforcement Evidence status
Debian 13 6.12 Stock function error injection is off. IA32 disablement alone is insufficient: native denial also fails. Use a suitable 7.1+ kernel, for example an available backports build, or a kernel with modifiable FEI targets; then disable IA32 effectively or prove all compat denial, activate BPF LSM and rerun qualification. Live-proven refusal on 6.12.113+deb13-cloud-amd64: 23 native denial gaps both with and without ia32_emulation=0, despite 26/26 LSM attachments. Effective IA32 disablement was live-proven by a separate SIGSEGV fixture; this was an earlier candidate payload, not a live pass of the final candidate.
Debian 12 6.1 Expected to need a kernel supplying native synchronous denial; inspect FEI and every target. This series has no upstream IA32 boot-disable parameter. If compat denial is unavailable, retaining 6.1 needs a custom-built kernel with IA32 compiled out; a newer replacement still needs all other checks. Expected; not live-proven for this candidate.
Ubuntu 22.04 GA 5.15 FEI-enabled builds are expected to supply native denial, pending target qualification. This series has no upstream ia32_emulation=0: prove compat denial or use a custom-built kernel with IA32 compiled out, or move to a suitable newer kernel. Activate BPF LSM if absent from the active stack. Expected; not live-proven for this candidate. FEI enabled is not a complete strict pass.
Ubuntu 24.04 GA 6.8 FEI-enabled builds are expected to supply native denial, pending target qualification. Prove compat denial or use ia32_emulation=0 and prove disablement. Activate BPF LSM if omitted from lsm=. Expected; not live-proven for this candidate in the reviewed evidence.
RHEL 8 4.18 Do not assume the older vendor kernel supplies the required BPF LSM/BTF or agent features. Use a qualified replacement or vendor-supported backports providing all required facilities and modifiable deny targets. There is no upstream IA32 disable parameter in this series; if compat denial is unavailable, retaining the series needs a custom-built kernel with IA32 compiled out and all other facilities supplied. Expected; not live-proven for this candidate. Compiling out IA32 alone does not make 4.18 compatible.
RHEL 9 5.14 Verify actual vendor BPF LSM, BTF and synchronous deny support; supply missing facilities with a suitable replacement or vendor-supported backports. There is no upstream IA32 disable parameter in this series; if compat denial is unavailable, retaining 5.14 needs a custom-built kernel with IA32 compiled out. Expected; not live-proven for this candidate.

Ubuntu 22.04 HWE using 6.8 follows the newer parameter path, unlike 22.04 GA. Later Ubuntu HWE/cloud kernels need their own checks; the GA row does not qualify them. Baseline series are documented by Ubuntu and Red Hat.

The other live-proven refusal in the reviewed agent evidence used 7.2.12+deb14-amd64, FEI off and IA32 enabled: native denial loaded, all 26 LSM programs attached, but 23 IA32 logical denial gaps remained. This establishes the native-versus-compat distinction, not strict readiness for Debian 14. No positive live strict pass is established by these reviewed candidate results. The boot-disabled positive agent branch and CLI acceptance have unit test evidence only. Earlier managed-platform results belong to their recorded agent/chart cohort; they do not qualify this candidate.

Check every node with the next CLI

Start with the next CLI's read-only assessment:

cloudtaser-cli assess --verbose

It prints one row per node, including cluster/pool/node, the installed protection tier, STRICT READY or STRICT BLOCKED, reason and remediation. Verbose output adds every checklist field in the first table, including unavailable items. Its actual field layout is:

  [STATUS] FIELD: VALUE; source: SOURCE
    Reason: DIAGNOSIS; Remedy: ACTION
  STRICT BLOCKED: qualification_unknown; source: no fresh measured strict agent qualification
    Remedy: Collect fresh host evidence with assess node-evidence on this node and the exact candidate agent's strict qualification JSON; rerun assess --node-evidence. Keep existing protection running.

The first two lines are a format template: STATUS is PASS, FAIL, BLOCKING, OBSERVED or UNKNOWN. OBSERVED records informational facts without awarding a pass. BLOCKING marks a prerequisite concern; the final strict verdict still requires the exact candidate agent's measured qualification. PASS on a raw config/sysctl field means its value was read, not that it is sufficient. In particular, an observed FEI=n can coexist with native eligibility on 7.1+. Missing permissions or host evidence stay UNKNOWN. STRICT BLOCKED can mean missing proof, not measured absence. Metadata alone cannot produce STRICT READY.

Assessment uses GET/LIST only. It never deploys probe Pods, execs into workloads or runs the privileged agent qualifier. Obtain the exact candidate's approved measured strict qualification JSON through its separate installation qualification workflow; that workflow loads and attaches BPF for qualification. Then collect host facts through approved node access, in the actual host namespaces, with the matching Linux CLI:

# On the workstation: record each actual Node name and UID.
kubectl get nodes -o custom-columns=NAME:.metadata.name,UID:.metadata.uid

# On each actual node, after obtaining candidate-qualification.json:
cloudtaser-cli assess node-evidence --node NODE --node-uid NODE_UID \
  --qualification candidate-qualification.json > node.json

# On the workstation, combine the per-node arrays if there are multiple nodes:
jq -s 'add' node-a.json node-b.json > nodes.json
cloudtaser-cli assess --node-evidence nodes.json --verbose
cloudtaser-cli assess --node-evidence nodes.json --json

For one node, pass node.json directly to --node-evidence. The host helper reads the listed files and runs the bounded IA32 child; it writes no executable to disk and loads no BPF. Without --qualification, host observations can identify prerequisites and blockers but cannot certify strict readiness.

Bind evidence to Node UID, kernel and boot ID, including the Kubernetes Node boot identity. Host observations and qualification must be no older than 15 minutes, with future clock skew at most one minute. Stale, replaced-node, reboot-mismatched or incomplete evidence cannot qualify. Imports are operator-supplied, not attestation. Rerun after any kernel, boot, candidate or capability change.

The CLI preserves the candidate agent's final measured decision, refused vectors, reason and remedy. STRICT READY requires measured strict qualification, explicit empty degraded modes and zero escape valves. It certifies that candidate's gate, not a future boot, x32 coverage, node-root tamper protection or workload delivery.

The installed tier and --min-tier exit contract remain separate. An exit 0 for Tier 2 can coexist with STRICT BLOCKED. Automation requiring strict readiness must inspect each node's kernel_readiness.verdict in JSON, rather than treating the tier exit as a strict pass. Resolve every unknown or refused requirement before moving protected workloads.