Procurement Brief: Kernel Hardening at a Glance

Subject: Root Lock by HeartSuite, kernel 5.19.6
Measured: 2026-05-19 using kernel-hardening-checker, an independent open-source tool
Full technical data: kernel-comparison-matrix-5.19.6.md

What this document covers

Every Linux kernel ships with hundreds of configuration choices that determine how easy it is to exploit vulnerabilities or escape security controls. This document compares HeartSuite’s kernel choices to a directly comparable community-hardened kernel and the KSPP industry benchmark.

All numbers on this page are outputs of the same measurement tool applied identically to each kernel configuration. No estimates. The Arch linux-hardened comparison uses the 5.19.11 release — the same kernel generation as HeartSuite 5.19.6, making scores directly comparable.

At a glance

KSPP benchmark anchored to kernel 6.17; its version-agnostic recommendations set the de facto industry target but are not directly score-comparable to 5.19.x.

What HeartSuite is optimized for

HeartSuite removes or disables the kernel features that are most commonly used to bypass security controls — not necessarily those used to exploit vulnerabilities.

This means:

• Attacker cannot use BPF to override security decisions at runtime. (Arch linux-hardened keeps BPF enabled; it’s widely used by system tools and container runtimes.)
• Attacker cannot use user namespaces (CONFIG_USER_NS=n) to create a fake root environment. (Arch linux-hardened 5.19.11 keeps user namespaces enabled for container use.)
• Attacker cannot use FUSE or overlay filesystems to confuse path-based enforcement.
• No competing security policies (AppArmor, SELinux at runtime, YAMA, Landlock, IMA, EVM) that could interfere with or be manipulated to weaken HeartSuite’s decisions.

What HeartSuite does not add — and dedicated hardened kernels do:

• Memory initialization on allocation/free (INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON)
• Bounds-checking on kernel-to-user copies (HARDENED_USERCOPY)
• Compiler-level hardening (FORTIFY_SOURCE, RANDSTRUCT, GCC_PLUGIN_LATENT_ENTROPY)
• Allocator randomization (SLAB_FREELIST_RANDOM, SLAB_FREELIST_HARDENED)
• Kernel stack erasure on syscall return (KSTACK_ERASE)

These mitigations slow down or prevent exploitation of kernel memory bugs. Arch linux-hardened 5.19.11 scores 69/109 (63.3%) on this axis vs HS’s 31/109 (28.4%). HeartSuite 5.19.6 sits at the vanilla upstream baseline for exploit-resistance. For deployments where the primary concern is a compromised process escaping its enforcement boundary — not kernel memory exploitation — HeartSuite covers the relevant threat at the right operating point; the Decision guide below covers when adding exploit-resistance hardening alongside HeartSuite makes sense.

Broader market landscape

Note: NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance and is no longer an active project. Qualitative characterizations are drawn from each project’s public documentation. Only HS and Arch linux-hardened scores are directly measured and era-matched.

Decision guide

Choose HeartSuite if your primary concern is:

• Preventing a compromised application from escaping its security boundary
• Ensuring no in-kernel feature (BPF, FUSE, namespaces) can be used to bypass your security policy
• Minimizing the total kernel attack surface (9 loadable modules vs. thousands)
• Running a single-purpose security appliance, not a general-purpose server

Consider adding a hardened kernel layer if your concern is also:

• Protection against kernel-level exploitation (heap corruption, use-after-free, ROP)
• Compliance requirements that enumerate specific KSPP mitigations
• Environments where root access cannot be fully constrained

HeartSuite is not a replacement for: network firewalls, application-layer WAFs, SIEM, endpoint detection/response — it operates at the kernel enforcement layer, not at the network or application layer.

Verification

HeartSuite’s kernel configuration is published with a SHA-256 hash. Any qualified security team can reproduce these measurements using the open-source kernel-hardening-checker tool:

Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: https://github.com/a13xp0p0v/kernel-hardening-checker (commit b9b83a0)

Full methodology and raw data: evidence-pack-5.19.6.txt