Kernel hardening

• 1: Kernel hardening in one comparison table
• 2: A custom kernel in a regulated fleet
• 3: Which distros boot the Root Lock kernel
• 4: How long each Root Lock kernel is maintained
• 5: Your scanner flags CVEs this kernel does not have
• 6: How to verify the kernel you downloaded
• 7: Which kernel evidence is published today
• 8: Hardening matrix for kernel 6.18.9
• 9: Hardening scores: 5.19.6 against the field
• 10: What a red team should test on this kernel
• 11: SELinux, AppArmor, TOMOYO — a different job
• 12: Kernel hardening in plain language

1 - Kernel hardening in one comparison table

Overview: Side-by-side comparison of Root Lock kernel configuration choices against community hardened kernels and the KSPP benchmark.

Subject: kernel that ships, 6.18.9-hs build #43 (packaging 6.18.9-HeartSuite-3). 5.19.6 is the legacy measured stream.
Evidence: tables below are the 2026-10-02 checker run, evidence-pack-6.18.9.txt (checker e870d01, 153/259). The 18 August guest boot is build #37, evidence-pack-6.18.9-2026-08-18.txt. Legacy: 5.19.6 matrix, evidence-pack-5.19.6.txt.

Kernel that ships: uname -r is 6.18.9-hs. The BPF syscall is off. CONFIG_IO_URING=y. CONFIG_KEXEC and CONFIG_KEXEC_FILE are unset.

For deployment, Secure Boot, fleet, and “no custom kernel” alternatives see the Enterprise Adoption Guide. Support and scanner notes: Kernel Support Policy, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this document covers

HeartSuite numbers below are outputs of kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac applied to the #43 packaging config (SHA-256 d6a08a04f4d6734adbafac431c3ebe46d339a495d907f1c6c569959321cc3684). Arch, vanilla, and KSPP rows are the 18 August 2026 run of that same commit.

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are the era-matched 6.18.x peers. Do not mix these percentages with the 5.19.6 pack, because its checker commit (b9b83a0) counts a different set of items.

At a glance (6.18.9-hs build #43, checker run 2026-10-02)

* KSPP is a recommendation fragment, not a shipping kernel.

Legacy 5.19.6 glance (checker b9b83a0, not comparable item-for-item): attack-surface 68.9% (91/132), exploit-resistance 28.4% (31/109). See the 5.19.6 matrix.

What changed between 5.19.6 and this pin

On 6.18.9-hs #43, exploit-resistance options INIT_ON_ALLOC_DEFAULT_ON, HARDENED_USERCOPY, FORTIFY_SOURCE, SLAB_FREELIST_RANDOM / _HARDENED, KFENCE, and MODULE_SIG are on. INIT_ON_FREE_DEFAULT_ON and MODULE_SIG_FORCE stay off. CONFIG_IO_URING=y. CONFIG_KEXEC and CONFIG_KEXEC_FILE are unset. bpf() returns ENOSYS.

The allowlist constrains programs that have no allowlist entry. On every HeartSuite-kernel boot, including Setup, heartsuite-kernel-latch.service sets kernel.modules_disabled=1 at sysinit, before sshd. A later modprobe stays refused. That latch is a boot script. HS_lockdown.sh writes the same setting again if the oneshot is masked.

Broader market landscape

Arch 6.18.16 is era-matched. The 5.19.6 row uses the older pack.

Decision guide

Choose Root Lock if your primary concern is:

• Kernel-enforced allowlist and Lockdown on a dedicated host
• A closed, reviewed program set after Setup Mode
• Running as a guest on KVM, VMware, or cloud hypervisors

Consider extra kernel hardening or a future derived cut if you also need:

• KSPP items still FAIL on this pack (INIT_ON_FREE, KSTACK_ERASE, MODULE_SIG_FORCE, …)

Root Lock is host-local kernel enforcement, so it does not replace network firewalls, WAFs, SIEM, or EDR hunting.

Verification

Packaging config SHA-256: d6a08a04f4d6734adbafac431c3ebe46d339a495d907f1c6c569959321cc3684
vmlinuz SHA-256:          f2e4749856f56cde87f9bcc887620f2d9b0aa2066756e4d3501326660b926c92
uname -r:                 6.18.9-hs
file(1) build:            #43
Tool: https://github.com/a13xp0p0v/kernel-hardening-checker (commit e870d0141259f875d3d1b54fef49dec7074e4cac)
Expected checker:         OK 153 / FAIL 106

Hash the packaging config. Guest /boot/config-6.18.9-hs is an 11-line initramfs stub. Full notes: evidence-pack-6.18.9.txt. The Debian 12 guest boot is build #37: evidence-pack-6.18.9-2026-08-18.txt.

2 - A custom kernel in a regulated fleet

Overview: Practical guidance for CISOs and procurement teams adopting the Root Lock kernel in regulated fleets — why the custom kernel exists, how vendor risk is owned, deployment and recovery patterns, and honest limitations including alternatives when a custom kernel is not acceptable.

Audience: Fortune 500 CISOs, procurement, risk, and compliance teams evaluating Root Lock by HeartSuite for production and regulated workloads.

Related reading: Start with the Procurement Brief (comparison table and decision guide) and Threat model (threat model and residual risks). Cross-references throughout this guide point to the full set of kernel-hardening, security, operational, and comparison pages.

Why a custom kernel

Root Lock uses a custom-built Linux kernel, mainline LTS 6.18.9-hs, so enforcement is in the kernel an attacker who already has remote root is running.

The BPF syscall is off by design. There is no eBPF program to load or unload.

A container runtime on this kernel is not a fit by design: under Lockdown, Root Lock refuses the new mounts a runtime makes. A KVM host on this kernel is not a supported configuration.

Root Lock does not rely on an unloadable eBPF policy.

Enforcement logic for program execution, file access, and outbound network connections is compiled into the kernel binary itself. Blocking decisions are consulted on every relevant operation. There is no runtime configuration file or agent that root can unload, kill, or reconfigure to disable protection.

This is distinct from “hardening mitigations” (stack canaries, allocator hardening, etc.). Those raise the cost of exploiting a memory bug. Lockdown bounds a compromised program to the files and destinations it was granted.

See the side-by-side scores and rationale in the Procurement Brief and the bypass table in How Root Lock Compares.

What Root Lock owns for kernel risk

Root Lock treats the kernel as an integrated part of the delivered product, not a third-party dependency the customer manages in isolation.

• Update cadence and patching: Kernels are released as coordinated versioned bundles with the userspace components (daemon, Dashboard, tools, and installer). After Lockdown, pick Maintenance: unseal and return to Root Lock at the console, land in Setup Mode on the Root Lock kernel, then apply the bundle over SSH — or reprovision from an updated image. Review new queue items before Lockdown again.

  Public patch targets, notification channels, and version-string semantics are in the Kernel Support Policy. Supported distributions and validation tiers are in the Distro Compatibility Matrix.

• CVE handling: Kernel Security Transparency is the status of each kernel CVE on the Root Lock kernel you boot: Not affected, Affected, or Fixed. Not affected means that option is unset, so the code is absent. A program with no allowlist entry does not run. An Affected row stays on the patch date. The long catalog also prints a Score on Root Lock beside that word. Scanner and audit workflows are in CVE Hygiene for Scanners.

• Stack pairing and testing: The kernel is built, tested, and supported together with the matching userspace. The full enforcement contract (VFS hooks + Lockdown seal + allowlist) is validated across supported distributions.

• Support SLAs: Commercial subscription terms cover the integrated stack, including kernel-related incidents, coordinated updates, and guidance on deployment and recovery. Activation and support details appear in the Subscription section and your subscription agreement.

Deployment mitigations: hiding kernel details in practice

Enterprise teams do not want operators making daily kernel choices. The product and recommended deployment patterns are built to keep the kernel choice at image-build or initial-provision time.

• Cloud Path: Pre-configured instances on major providers (AWS, Google Cloud, Azure, DigitalOcean, Linode, and others) arrive with the Root Lock kernel already installed and set as default. The Dashboard appears on first login with initial setup complete. Serial console access from the provider remains available for recovery.

• Automated install: Packer, Terraform, Ansible, or cloud-init still land each host on Cloud Path (pre-built image) or Local Path (run the installer). The installer sets the Root Lock kernel as the GRUB default, performs the initial boot, and surfaces the Dashboard. Baseline allowlists can be pre-seeded for homogeneous fleets (see Central Policy).

• Hiding details from operators: After initial provisioning, day-to-day interaction is through the Dashboard or central automation. Kernel selection appears only in the documented Maintenance flow (when changes are required) and in the System Info Strip when running on the maintenance kernel.

  GRUB entries for the original distribution kernel are retained for the recovery path, split into Maintenance and vanilla entries, with Maintenance labelled as the Setup Mode destination.

Official pre-built images in the major cloud Marketplaces are in active development and will further reduce the need for customers to assemble images. Until those listings are available, the pre-configured-image + automated-install pattern delivers equivalent repeatability and auditability. Use the same tooling you already apply to other base OS images.

Secure Boot, firmware compatibility, and roadmap

Current status: Root Lock kernel support for UEFI Secure Boot (including MOK enrollment on local hardware and provider-specific flows such as Azure Trusted Launch and GCP Shielded VMs) is incomplete.

Deployments that require Secure Boot enabled for the Root Lock kernel entry may need to enroll via MOK during installation. Alternatively, temporarily boot with Secure Boot disabled for the Root Lock kernel while using the provider console or local management for the maintenance kernel.

The original distribution kernel (maintenance kernel) retains its signing status and can be used for recovery and maintenance regardless of Secure Boot policy.

Roadmap: Signed kernel images, streamlined MOK tooling, and cloud-provider-specific runbooks (Azure, GCP, AWS) are prioritized work.

Customers evaluating platforms with mandatory Secure Boot should engage support for the current test status and any interim runbooks applicable to their cloud account or hardware.

The bypass-prevention properties (physical or serial-console access required for any recovery path) hold on both the Root Lock kernel and the maintenance kernel. Secure Boot is an orthogonal boot-integrity control.

Compatibility and certification

Root Lock is designed to coexist with the majority of enterprise infrastructure components that do not themselves depend on the disabled kernel features.

Works with (standard configurations):

• Local and cloud block storage (ext4, xfs, and provider volumes) for the root and data filesystems.
• Standard networking stacks and cloud provider vNICs / security groups (Root Lock controls only outbound per-program destinations; inbound remains the responsibility of the OS firewall or cloud controls).
• SIEM / SOAR ingestion via the two syslog streams and webhook (see Alert Settings).
• Monitoring and status collection via ~/.cache/heartsuite/status.json (Ansible facts, Nagios, Zabbix, custom collectors).
• EDR and observability via log forwarding (no on-host eBPF attachment): enforcement events flow through syslog, and the denial log records blocks only.
• Vulnerability scanners and HIDS/FIM agents (run during Setup Mode so their programs and paths are reviewed and approved).

Does not run on the Root Lock kernel (use a kernel that still has these features, a separate host, or alternative controls):

• Local execution of eBPF-based tools (Falco, Cilium Tetragon, bpftrace, etc.) — not a fit by design. The BPF syscall is off, so there is no eBPF program to load.
• Docker, containerd, Kubernetes, CRI-O, and Podman on this host, including a fixed pod set, are not a fit by design. Under Lockdown, Root Lock refuses the new mounts a runtime makes. OCI images are built and run off this host, or Root Lock is the guest kernel in a VM the customer provides.
• KVM hypervisor hosts. Root Lock runs as a guest.
• Rootless / unprivileged user-namespace containers are not a fit by design. Under Lockdown, Root Lock refuses the new mounts a runtime makes.
• Any workload that needs a kernel option the 6.18.9-hs config leaves unset.

Decision tree (high level)

Full compatibility notes and known non-fits live in How Root Lock Compares (section “Where a separate kernel is required”) and the system-requirements pages. As more storage, networking, EDR, and monitoring vendors publish explicit coexistence statements, this section will be expanded with a published matrix.

Operational model for fleets

Each host still installs through Cloud Path or Local Path. The Root Lock kernel is managed the same way you manage base OS images and policies — through the control planes you already own.

• Image lifecycle: Treat the Root Lock kernel + baseline allowlist as part of your pre-configured image. Harvest an install-time baseline, package with that seed, bake with Packer or your image pipeline, then replace instances on the same cadence as your other images. See Central Policy.
• Provisioning: Terraform, cloud-init, or your IaC tool launches the image (or runs the installer non-interactively). No special kernel module or agent is required after boot.
• Policy at scale: Allowlist content (programs, file paths, network destinations) is curated centrally and applied via Ansible, Terraform + GitOps, ServiceNow, or custom automation exactly as described in Alert Settings (fleet export surfaces and central policy patterns). Pre-seeding accelerates homogeneous fleets; observation + central review handles varied workloads.
• Kernel updates: Delivered as versioned bundles. If Lockdown is applied, unseal first. Then run the bundle from Setup Mode and type YES, which sets the next boot only to the stock kernel while Root Lock stays the default — or reprovision from an updated pre-configured image. See Updating Root Lock and the pre-configured image alternative.
• Observability and drift: status.json, the JSONL approval log, and the two syslog streams feed your existing fleet dashboards and SIEM. Drift detection (policy or mode) is performed by harvesting from central jobs and comparing against the Git/CMDB source of truth.
• No new kernel-specific fleet tooling: The same rsyslog rule, SSH/Ansible access, and image pipeline you use today handle the kernel boundary.
• Locked-fleet patches: In-place package installs and in-place Root Lock bundles need Setup Mode, and after Lockdown that window opens from physical or serial-console access on that host. Ansible does not unseal. For many hosts, bake the patched OS and the current Root Lock bundle into a new image and reprovision the instances.
• Console and disk: The cloud serial console (AWS EC2 Serial Console, GCP Serial Console, Azure Serial Console, DigitalOcean Console) is recovery and break-glass, not a way to patch a fleet. Restrict it in cloud IAM. Stopping a VM and attaching its volume elsewhere is hypervisor access — the same trust boundary as the console, not a supported patch procedure. See Circumvention and recovery.

This model keeps ownership of policy curation, change records, and visibility inside the tools your teams already run.

Commercial subscription and kernel support

A commercial subscription for Root Lock covers the delivered stack, including the kernel:

• Vendor support and SLAs for incidents, updates, and deployment guidance that encompass kernel behaviour, as set out in the subscription agreement.
• Access to the verification artifacts published on this site (config hashes, evidence packs, CVE transparency data) for customer due diligence.
• Coordinated release process so that kernel changes, userspace changes, and documentation remain in sync.

The kernel does not carry a separate support contract. It is part of the integrated product under the same subscription that enables Lockdown.

Indemnity, limitation of liability, and SLA credits are contract terms. Residual kernel CVE risk stays with you. See the Subscription page for activation mechanics and your agreement for the binding text.

Supply chain transparency and integrity

• Reproducible posture verification: Every released Root Lock kernel includes a published SHA-256 of its exact .config file. Any team can obtain the config from the kernel package and re-run the open-source kernel-hardening-checker to reproduce the exact attack-surface and exploit-resistance scores shown in the Procurement Brief and Threat model.

  See evidence-pack-*.txt files for raw output.

• Installer and bundle integrity: Distributed bundles include SHA-256 manifests (.sha256 files) for verification before execution.

• SBOM and provenance: A full software bill of materials covering the kernel and userspace components, plus expanded reproducible-build artifacts and signing for kernel binaries, is in active development. Current customers receive the available verification material (config hash + evidence packs + bundle hashes) under their subscription. Additional supply-chain artifacts are provided on request or as they become available. Public roadmap and interim controls: Supply Chain and Advisory Feeds. Per-stream evidence publication: Evidence Status.

• No reliance on opaque vendor claims for the measured hardening posture: The numbers are tool outputs against public hashes.

Recovery and fallback: the maintenance kernel as supported escape hatch

Every installation retains a first-class recovery path:

• The original distribution kernel is always present in GRUB (split into Maintenance and vanilla entries during install, with Maintenance labelled as the Setup Mode destination).
• The Dashboard’s Maintenance flow ([m]) detects Lockdown state and guides you through the exact sequence for the common case: reboot at the console, pick Maintenance: unseal and return to Root Lock, land in Setup Mode on the Root Lock kernel, make changes over SSH, review new activity, and re-engage Lockdown.
• For policy or platform conflicts that make the Root Lock kernel unsuitable for an extended period, teams can remain on the maintenance kernel (the product continues to run and log in non-enforcing mode) or remove Root Lock entirely. Both paths are supported and documented.
• Physical or serial-console access (local keyboard/monitor, serial, or cloud provider serial console) is always sufficient to select the maintenance kernel and regain full control when the boot menu password is left off. No software on the system can block that path while the password stays off. If one was set, GRUB asks before Maintenance: unseal and return to Root Lock or a kernel-line edit, and a forgotten password is cleared by mounting the disk from outside, not at the menu. The normal boot still does not ask.

This is the documented, supported escape hatch for operational needs, kernel policy conflicts, or environments that ultimately decide against a custom kernel. Full procedures appear in the Maintenance section and FAQs.

Evidence and independent verification for customers and auditors

Nothing on the kernel posture page relies on “trust us.”

• Reproduce hardening measurements yourself with the published config SHA-256 and the open-source checker (full commands in Threat model).
• Review every relevant CVE on the Kernel Security Transparency page. The word you file is Not affected, Affected, or Fixed.
• Inspect live state via the status JSON, per-decision syslog events, approval log, and the sealed allowlist files (all readable or harvestable without special privileges beyond normal admin access).
• For procurement and due-diligence packages: attach the Procurement Brief, threat-model page, comparison matrix, and evidence packs to an RFP or vendor questionnaire. The customer’s control testing still has to stand on its own.

Honest limitations

Root Lock with the Root Lock kernel is a deliberate architectural choice that trades general-purpose kernel compatibility for bypass resistance against a compromised root account. It is not the right fit for every environment.

Organisations with formal “no custom kernel,” “no modified kernel,” or “vendor-certified kernel only” policies (driven by support contracts, regulatory certification of the base OS, or internal change-control mandates) should not adopt the Root Lock kernel.

In those cases the supported path is:

• HeartSuite Joint File System (HJFS) — a filesystem-based enforcement layer that provides per-program, per-version file isolation and automatic backup/rollback on a completely standard kernel. No kernel replacement is required.

  HJFS is deployable on cloud instances where the kernel is provider-managed and on systems under strict kernel certification rules. See the full HJFS documentation (overview, deployment scenarios, limits, and how it complements execution/network controls).

• Layered controls on the standard kernel (SELinux or AppArmor in enforcing mode, seccomp filters, eBPF-based detection where needed, network egress filtering, EDR, vulnerability management, and HIDS). Root Lock’s execution and network gating concepts are not applicable without the Root Lock kernel.

• Where both file isolation and execution/network gating are required under a no-custom-kernel constraint, HJFS plus existing host tooling is the evaluated combination. HeartSuite Exec is the HJFS program UI; it does not add those gates.

The HJFS how-it-compares and limits pages, together with the bypass and circumvention sections of How Root Lock Compares, give procurement teams the material needed to map requirements to the appropriate product or combination.

Root Lock positions the Root Lock kernel for the subset of workloads where the documented properties (compiled enforcement, physical- or serial-console recovery, and Lockdown) justify the kernel change.

Next steps for enterprise evaluation

1. Read the Procurement Brief decision guide and run the published measurements on a test deployment.
2. Review the Threat model and the full CVE transparency page.
3. Pilot using a cloud pre-configured instance or a Packer-built pre-configured image on a non-production workload.
4. Map your compatibility requirements against the decision tree and the “where a separate kernel is required” section of How Root Lock Compares.
5. For platforms with Secure Boot or Marketplace requirements, request current runbook and timeline status from support.
6. For strict no-custom-kernel policies, evaluate HJFS in parallel.
7. Engage commercial discussions for subscription terms, support SLAs, and any additional verification artefacts.

The kernel is one component of a larger control. The surrounding pages (central policy management, SIEM integration, maintenance, and comparison material) describe how the rest of the operational model fits into an enterprise security program.

Posture claims on this page follow the fielded pin in Evidence Status. Last updated: 2026-09-11.

3 - Which distros boot the Root Lock kernel

Overview: Which Linux distributions Root Lock by HeartSuite currently tests, which kernel line each row uses, and what you still own before production Lockdown. This page follows the live-matrix catalog and the installer floors as of 2026-09-24. The April 2026 v1.6.4 “Validated” table (Fedora 41, Alpine 3.21 as validated, Ubuntu 22.04 omitted) stays retired.

Audience: Procurement, security architects, and platform engineers selecting a base OS.

This matrix complements the workload notes in System Requirements and the buyer-facing deployment guidance in the Enterprise Adoption Guide.

How to read this matrix

Each row assigns a tier that says what HeartSuite has run recently and what you own:

Columns

• Kernel line — Which Root Lock kernel the current installer for that row ships. Debian 12, Debian 13, Ubuntu 24.04, and Ubuntu 26.04 use 6.18 (uname -r is 6.18.9-hs on the fielded pin). Debian 11 and Ubuntu 20.04 use 5.19 only, as lab re-proof of the legacy k5 line. Ubuntu 22.04 is not offered on this installer. You do not pick both lines at install on a given row.
• Boot — How the installer sets the default kernel entry. UEFI Secure Boot for the Root Lock kernel entry remains incomplete. The original distribution kernel (maintenance kernel) keeps its signing status for recovery. On GRUB, including Fedora and Red Hat, an optional boot menu password can be set from Lockdown before the seal (Lockdown).

Source for rows and kernel series: heartsuite/tools/live_matrix/distro_catalog.yaml, plus the installer floors (glibc 2.34, Python 3.11), as of 2026-09-24.

Main compatibility table

Architecture: x86_64 (64-bit) only. No ARM or other ISA builds are offered for the Root Lock kernel.

Installer floors (current 6.18 bundle): glibc 2.34 or newer, and Python 3.11 or newer. A host that misses either floor is not a gold-image trial. Debian 11 and Ubuntu 20.04 stay on the 5.19 installer. There is no compat package that puts the 6.18 helpers on an older userland.

Secure Boot (all distributions): Root Lock kernel UEFI Secure Boot support is incomplete.

Deployments that require Secure Boot for the Root Lock entry may need MOK enrollment during install. Alternatively, boot the Root Lock kernel with Secure Boot disabled while retaining the signed maintenance kernel. Details: Enterprise Adoption Guide → Secure Boot.

Tier definitions

Supported

The distribution is in the current k6 release-core set (Debian 12, Debian 13, Ubuntu 24.04, Ubuntu 26.04). HeartSuite runs install, first boot, and initial setup against it in the live matrix. Lockdown on that set is not a published green sign-off. Your staging Lockdown run is the last gate before fleet rollout.

In lab

The distribution is in the current catalog with a documented caveat (btrfs preflight, not certified, last green date older than the current bundle). Commercial support still applies when install and Lockdown succeed on the customer image.

Experimental

Catalog experimental, or rolling / not certified. Expect extra reboots, boot-loader edge cases, or a missing release sign-off.

Legacy (5.19 only)

Debian 11 and Ubuntu 20.04 use the k5 installer and the 5.19 Root Lock kernel for lab re-proof. The 6.18 bundle is for the current line, and the installer refuses it on these two hosts.

Compatible (customer validation)

Same packaging family as a tested row. HeartSuite has not published results for your exact vendor branding, minor, or gold image. The glibc 2.34 floor and the Python 3.11 floor still apply. RHEL 8, RHEL 9, AlmaLinux 8, and AlmaLinux 9 are not a customer-validation exercise on this installer.

Not supported

Outside current product scope. That includes Ubuntu 22.04 and the EL9 family (Rocky Linux 9, AlmaLinux 9, RHEL 9, CentOS Stream 9), which miss the Python floor, and releases below glibc 2.34 (RHEL 8, AlmaLinux 8, CentOS 7, RHEL 7, CentOS Stream 8, Debian 9, Debian 10, Ubuntu 18.04). Use a distribution this installer accepts, or HJFS on a standard kernel where custom kernels are prohibited.

RPM / RHEL family

The current installer needs glibc 2.34 or newer and Python 3.11 or newer. Rocky Linux 10 and CentOS Stream 10 clear both and stay experimental. Rocky Linux 9, AlmaLinux 9, RHEL 9, and CentOS Stream 9 clear glibc and fail the Python floor, so the installer refuses them. RHEL 8 and AlmaLinux 8 ship glibc 2.28.

SELinux on RHEL-family systems: Root Lock VFS hooks are designed to run before the LSM chain, so SELinux can add restrictions after Root Lock allows an operation and cannot lift a Root Lock denial. A targeted SELinux policy module may still be needed for product paths. If AVC denials appear, use ausearch and audit2allow. Hook-order detail: LSM Comparison → Co-existence. That LSM page is still written against the 5.19.6 measured pack — do not treat it as the 6.18.9-hs LSM list.

Debian and Ubuntu family

Debian 12, Debian 13, Ubuntu 24.04, and Ubuntu 26.04 are the current k6 release-core set and the majority of documentation examples.

On Debian/Ubuntu the installer sets the Root Lock kernel as the GRUB default and reboots when GRUB automation succeeds. The original distribution kernel remains in GRUB as Maintenance and vanilla entries for recovery.

Alpine Linux

On Alpine extlinux the boot menu password is not offered, and Lockdown still works.

SUSE family

Cloud platforms (AWS EC2 Nitro and KVM guests)

Root Lock runs as a guest on AWS EC2 (including Nitro), KVM, VMware, and other cloud hypervisors. Use a distribution from this matrix and the same installer as on local hardware. For nested guests, see Bare metal, virtual machines, and nested VMs.

Before you install on a cloud instance:

• Keep the provider serial console enabled. SSH can drop during the first Root Lock reboot; the console is how you recover if the instance does not come back.
• Run the install once on your target instance type in staging before fleet rollout.
• If the installer stops before reboot, read /var/log/heartsuite/install.log and email support@heartsecsuite.com with the log attached.

Root Lock as a hypervisor host (running VMs from this kernel) is not a supported product role. See Workload fit.

Workload fit (not distro-specific)

Distribution compatibility answers whether Root Lock installs and boots on your base OS. Whether a workload belongs on that host is a separate decision.

On the kernel that ships, the BPF syscall is off by design, so there is no eBPF program to load.

For Docker, containerd, Kubernetes, CRI-O, and Podman, OCI images are built and run off this host, or Root Lock is the guest kernel in a VM the customer provides.

Full exclusion table: System Requirements. Mixed-environment decision tree: Enterprise Adoption Guide → Compatibility.

HJFS alternative

Organizations with a strict no custom or modified kernel policy — certification rules, cloud provider-managed kernels, or vendor OS support contracts that forbid replacing the distribution kernel — should not force the Root Lock kernel onto those images.

HeartSuite Joint File System (HJFS) provides per-program, per-version file isolation and automatic backup on a standard kernel. No kernel replacement is required.

HJFS limits and comparison: HJFS how-it-compares and HJFS limits. Procurement mapping: Enterprise Adoption Guide → Honest limitations.

Reporting issues

If install or Root Lock kernel boot fails on a Supported, In lab, Experimental, Legacy, or Compatible distribution, email support with enough context to reproduce:

Email: support@heartsecsuite.com

Include:

1. /var/log/heartsuite/install.log — installer steps and outcome (see Appendices).
2. Kernel identity: output of uname -r.
   • Current 6.18 stream: expect 6.18.9-hs. The packaging label is 6.18.9-HeartSuite-3 (build #43). uname -r does not contain the word HeartSuite. A distribution version string means the maintenance kernel is running.
   • 5.19 legacy: expect a string such as 5.19.6-HeartSuite-2.0.
   • Maintenance kernel: a distribution version string with no Root Lock packaging (for example a stock debian or el uname).
3. OS identity: contents of /etc/os-release.
4. Root Lock version and whether the failure occurs during install, first Root Lock boot, initial setup, or Lockdown.
5. Boot loader (GRUB vs extlinux) and whether UEFI Secure Boot is enabled.

For non-blocking bugs on supported platforms, open a GitHub issue using the Bug Report template on the public repository. Do not use public issues for security vulnerabilities — email support@heartsecsuite.com for responsible disclosure.

Kernel update recovery if a new Root Lock kernel fails to boot: Updating Root Lock.

Related reading

• Kernel Support Policy — LTS strategy, patch targets, version-string semantics, and notification
• System Requirements — Architecture, kernel lines, and software notes
• Enterprise Adoption Guide — Secure Boot status, fleet operations, procurement decision tree
• LSM Comparison — SELinux co-existence (5.19.6 measured pack)
• Procurement Brief — Hardening posture comparison (6.18.9-hs build #43)
• CVE Hygiene for Scanners — Scanner workflow; do not infer 6.18 compile-out from 5.19 greps
• How Root Lock Compares — What belongs on a separate host
• Deployment Scenarios — Where Root Lock fits
• HJFS documentation — Standard-kernel alternative
• Before You Begin — Prerequisites and cloud vs local install paths

Last updated: 2026-10-02. Rows follow distro_catalog.yaml and the installer floors (glibc 2.34, Python 3.11). Workload Kconfig values are from the 6.18.9-hs #43 packaging config and the published 5.19.6-HeartSuite-1.0 pack. No complete Lockdown M2 release-core gate is claimed for this date.

4 - How long each Root Lock kernel is maintained

Overview: How HeartSuite maintains, patches, and delivers the Root Lock kernel under subscription — LTS strategy, coordinated update bundles, and how that differs from distribution-vendor errata programs such as RHEL.

Audience: Procurement, risk, compliance, and platform teams evaluating Root Lock kernel maintenance alongside existing distribution patching programs.

Related reading: Enterprise Adoption Guide, Updating Root Lock, Kernel Security Transparency, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this policy covers

This policy describes how HeartSuite supports the Root Lock kernel — the custom-built Linux kernel that Root Lock by HeartSuite requires for Lockdown enforcement — under a commercial subscription.

It applies to:

• Root Lock kernel stream currently shipped and supported:
  • 6.18 — primary LTS stream and commercial baseline (HeartSuite v1.6.4 ships kernel 6.18.9).
• 5.19 — legacy line for lab re-proof on Debian 11 and Ubuntu 20.04. Those hosts take the k5 installer. New images take the 6.18 bundle.
• Coordinated update bundles that deliver the Root Lock kernel together with matching userspace components (Dashboard, daemon, tools, and installer). Kernel changes are not published or supported as standalone kernel-only packages outside these bundles.
• Integration with subscription terms — patch targets, notification channels, and binding service-level commitments appear in your subscription agreement. This page states public targets and operational boundaries so buyers can align internal change-control and vulnerability-management programs before contract signature.

Note: This policy does not replace the subscription agreement. Where this page and your agreement differ, the agreement controls.

LTS-only strategy

HeartSuite’s current commercial baseline is a mainline LTS kernel (6.18). New streams are LTS bases — not arbitrary upstream version chasing.

The 5.19 stream is the legacy line. It was a short-lived mainline release. Debian 11 and Ubuntu 20.04 keep it for lab re-proof of the k5 installer. Fleets already on 5.19 use the schedule in 5.19 stream deprecation.

Why LTS-only

• LTS branches receive upstream security and stability maintenance for a defined period, which gives HeartSuite a predictable rebuild base.
• HeartSuite’s security model depends on a fixed, published kernel configuration (the BPF syscall off, enforcement hooks, and Lockdown integration). Rebuilding on a known LTS tag preserves that contract while absorbing upstream fixes that apply to the compiled-in code paths.
• Chasing every upstream minor release would multiply validation cost without improving the enforcement properties buyers adopt Root Lock for.

Commercial baseline

• New subscriptions and new fleet images should standardize on the 6.18 stream.
• HeartSuite v1.6.4 (April 2026) established 6.18.9 as the commercial release baseline for multi-distribution support.

When HeartSuite advances the LTS base (for example, a future move within the 6.18 LTS line or to a subsequent LTS series), customers receive advance notice and migration bundles as described under Customer notification and 5.19 stream deprecation.

How HeartSuite differs from the distribution-vendor model

Enterprise Linux distributions such as RHEL follow a frozen-base, backport-within-base model. The upstream kernel version number visible in uname stays on a vendor branch for years, while individual CVE fixes are cherry-picked onto that branch. Vendor errata, advisory identifiers, and scanner feeds are built around that model.

HeartSuite follows a different model, aligned with how Root Lock is built and validated:

The Root Lock kernel is not a drop-in substitute for a distribution kernel in every operational sense, because it is built as the enforcement kernel for Lockdown.

The distribution maintenance kernel remains on the system for maintenance and recovery. Distribution errata still apply to packages and to the maintenance kernel path.

For deployment implications, coexistence with distribution maintenance, and fleet patterns, see the Enterprise Adoption Guide.

Root Lock kernel version string anatomy

The running kernel version is shown by uname -r. On a Root Lock deployment, the string identifies the HeartSuite build, not a distribution errata package.

Fielded 6.18 pin: uname -r is 6.18.9-hs. The packaging label is 6.18.9-HeartSuite-3, so the absence of the word HeartSuite in uname -r does not mean you are on the maintenance kernel.

Legacy 5.19 example: 5.19.6-HeartSuite-1.0

On 6.18, tell the Root Lock kernel from the maintenance kernel with uname -r plus file on vmlinuz, as documented in Evidence Status.

What the version string does not mean

Procurement and scanner teams trained on distribution errata often misread custom kernel strings. The Root Lock kernel version string does not imply:

• Full upstream parity — The string does not assert that every fix present in a newer upstream kernel is backported. HeartSuite rebuilds on the LTS base with the published HeartSuite configuration; fixes apply to compiled-in paths or are addressed through structural absence and Lockdown bounds as documented on the Kernel Security Transparency page.
• Distribution errata equivalence — A match against a distribution CVE feed or rpm -q kernel version is not valid for the Root Lock kernel, because the Root Lock kernel is not a distribution kernel package.
• Scanner “fixed in version” logic — Vulnerability scanners that compare uname -r to NVD “fixed version” thresholds will produce false positives for Root Lock kernels. Use HeartSuite’s per-CVE status and CVE Hygiene for Scanners guidance instead of raw version-string matching.
• kABI or DKMS compatibility — The string does not promise binary compatibility with out-of-tree kernel modules built for the distribution kernel or for prior HS builds.
• Live-patch level — There is no parallel “kpatch level” or running-patch suffix; updates require a coordinated bundle and reboot path.
• Secure Boot readiness — Version format does not indicate UEFI Secure Boot signing status for the Root Lock kernel entry. Secure Boot support for the Root Lock kernel remains incomplete; see the Enterprise Adoption Guide for current status.

For independent verification of what is in the build, HeartSuite publishes the kernel .config SHA-256 and evidence packs for each supported stream.

Update delivery

Root Lock kernel updates are delivered only as part of coordinated HeartSuite release bundles.

Bundle format and integrity

• Updates ship as a self-extracting heartsuite-install.sh bundle with a published heartsuite-install.sh.sha256 checksum file.

• Before execution, verify integrity:

  sha256sum -c heartsuite-install.sh.sha256
  

  Expected output: heartsuite-install.sh: OK

• Each bundle updates the Root Lock kernel, userspace tools, Dashboard files, and GRUB defaults together so the enforcement stack stays paired and tested.

Applying an update

The installer will not overwrite Root Lock while that kernel is booted, so the update finishes on one stock or maintenance boot.

1. If Lockdown is applied, unseal from the console first, because the installer cannot set the next boot while /boot is sealed. The unseal is a separate boot from the one that installs the update.
2. From a terminal in Setup Mode, run bash heartsuite-install.sh and type YES. The installer sets the next boot to the stock or maintenance kernel, continues the update after that boot, and keeps Root Lock as the default.
3. If you are already on the original distro kernel or the maintenance kernel and Lockdown is not applied, run the installer without a YES step.

Root Lock is not loaded on that stock or maintenance boot, so it does not block, log, or take backups. Choose a time when that gap is acceptable.

Full step-by-step procedures, failure recovery, and Lockdown considerations are in Updating Root Lock.

Pre-configured image alternative

Teams that provision from images may reprovision from an updated pre-configured image instead of in-place bundle application. This is equivalent from a support perspective when the image contains a bundle version HeartSuite has published for that stream.

Image pipelines should pin bundle version, checksum, and Root Lock kernel string in build metadata for audit traceability.

In-place bundle application after Lockdown still needs the console unseal on that host. Teams that will not open a console on every node should treat image reprovision as the fleet path. Package installs on a live sealed host are a different job — Protecting During Maintenance.

Patch commitment tiers

HeartSuite classifies kernel-related security work using the reachability model on the Kernel Security Transparency page. The tables below are public targets for coordinated bundle delivery. Binding SLAs — including business-day definitions, escalation, and credit terms — are set in your subscription agreement.

Clock start for timed tiers: HeartSuite confirmation that the issue applies to the supported Root Lock kernel stream (reachable path or required rebuild), based on upstream vendor/public confirmation and HeartSuite analysis.

Notes

• A CVE is Not Affected on the kernel you boot only where that config leaves the option unset, and those entries do not consume patch-tier clocks. On 6.18.9-hs the BPF syscall is one of those, so there is no eBPF program to load.
• For reachable CVEs, Lockdown limits persistence and arbitrary code execution even before a rebuild ships; patching remains part of defense-in-depth and subscription commitments for reachable paths.
• HeartSuite does not issue per-CVE errata identifiers in the distribution-vendor style; bundle manifests list the CVEs addressed in each release.

Customer notification

HeartSuite notifies subscription customers through the following channels:

Major stream deprecation: HeartSuite provides at least 30 days’ advance notice before ending support for a Root Lock kernel stream (for example, end of 5.19 support). Notice includes migration bundle availability and recommended maintenance windows.

For the current release (hs-v1.6.4-kernel-6.18.9, gate_status: PASS): CONFIG-gate Not-Affected SBOM at /advisories/hs-cve-config-sbom.json, OSV at /advisories/osv.json (279 entries), and CycloneDX SBOM at /advisories/sbom.cyclonedx.json.

OVAL XML for OpenSCAP is not yet published. Use the JSON feeds, CVE transparency page, bundle manifests, and email advisories as authoritative sources. Feed URLs and schemas: Supply Chain and Advisory Feeds.

5.19 stream deprecation

The upstream 5.19 branch is end-of-life. New deployments and new pre-configured images use the 6.18 line.

Support window for existing deployments

• HeartSuite continues to ship 5.19 migration and security bundles for deployments already on the 5.19 HS stream through end of calendar year 2026, subject to subscription status.
• After that date, 5.19 Root Lock kernel support ends unless extended terms are agreed in writing. Email support@heartsecsuite.com before the cutoff to plan fleet migration.

Migration path

1. Schedule maintenance using Updating Root Lock (or reprovision from a 6.18 pre-configured image).
2. Apply the published 5.19 → 6.18 migration bundle for your distribution and HeartSuite version.
3. Reboot into the 6.18 Root Lock kernel, review Dashboard queues for any new program activity, and re-engage Lockdown if required.
4. Update vulnerability-management and configuration baselines to reference the new version string and published 6.18 config hash.

Functional differences between streams (configuration and CVE tables) are summarized in the Distro Compatibility Matrix and stream-specific evidence materials.

Support boundaries

Subscription scope

• The Root Lock kernel is included in the Root Lock subscription. There is no separate kernel-only support contract.
• Incidents, rebuild requests, deployment guidance, and coordinated updates for kernel behaviour are handled under the same subscription that enables Lockdown.
• Verification artifacts (config SHA-256, evidence packs, CVE transparency data, bundle checksums) are provided as part of the product documentation and subscription deliverables.

Coexistence with distribution subscriptions

On a host running Root Lock:

Root Lock replaces the enforcement kernel for protected operation; it does not remove the distribution kernel or cancel distribution maintenance obligations on the maintenance-kernel path. During maintenance on the maintenance kernel, the host behaves as a standard distribution system without Lockdown enforcement.

Distribution-vendor subscriptions (RHEL, SLES, Ubuntu Pro, and similar extended-support offerings) and third-party agents that require the distribution kernel for full functionality continue to apply to the maintenance-kernel path and to userspace packages.

Agents or tools that need the BPF syscall should run on a kernel that exposes it, or on a separate host. See the Enterprise Adoption Guide compatibility section.

What Root Lock does not provide

Root Lock does not offer the following on the Root Lock kernel path:

If a workload requires live patching, vendor-certified unchanged distribution kernels, or broad third-party kernel module support as non-negotiable constraints, evaluate the maintenance-kernel path, HJFS on a standard kernel, or layered controls described in the Enterprise Adoption Guide rather than the Root Lock kernel.

Related reading

• Enterprise Adoption Guide — Deployment, fleet operations, Secure Boot status, risk ownership, and compatibility decision tree.
• Updating Root Lock — Bundle verification, update procedure, and recovery.
• Kernel Security Transparency — Per-CVE status, Not Affected rationale, and Score on Root Lock.
• Distro Compatibility Matrix — Supported distributions, kernel streams, and coexistence notes.
• CVE Hygiene for Scanners — Resolving scanner false positives against HS version strings.
• Supply Chain and Advisory Feeds — Published CONFIG SBOM, OSV, and CycloneDX feeds; GPG/cosign and OVAL roadmap.
• Evidence Status — Per-stream config hash and checker publication status.

This page is procurement- and operations-facing. Patch targets are goals for planning; binding commitments are in your subscription agreement. Last updated: 2026-06-23.

5 - Your scanner flags CVEs this kernel does not have

Overview: How to verify kernel CVE status on Root Lock hosts without false positives from upstream version comparison — the workflow vulnerability scanners and auditors should follow instead of matching uname -r to NVD fix versions.

Audience: Security operations, vulnerability management, GRC, and audit teams on enterprise Linux (RHEL and Rocky, Ubuntu LTS, Debian, SUSE) who verify kernel CVEs with distribution errata rather than upstream version strings — and who are evaluating or operating Root Lock by HeartSuite in production.

Related reading: Start with Kernel Security Transparency (per-CVE status and rationale), the Procurement Brief (posture at a glance), and the Threat model (threat model and reproduction commands).

Why vulnerability scanners get HeartSuite wrong

Most enterprise vulnerability scanners were built for distribution kernels. They match the running kernel version string against NVD or vendor feeds that assume a vanilla upstream Linux kernel — the same tree, configuration, and feature set as kernel.org.

Root Lock does not ship a vanilla upstream kernel. It ships a custom configuration on an LTS base (mainline 6.18.9; uname -r is 6.18.9-hs).

The version string tells you the LTS line. It does not tell you which subsystems are compiled in, which CVEs are reachable, or whether a backported upstream fix is relevant.

When a scanner sees 6.18.9-hs, it typically:

1. Normalises the string to 6.18.9 (or fails to recognise the suffix entirely).
2. Compares that version against NVD “fixed in” ranges for the upstream kernel (for example, “fixed in 6.18.12”).
3. Flags the host as vulnerable without checking whether the vulnerable code path exists in the HeartSuite build.

That produces false positives — often hundreds of them — for CVEs where HeartSuite’s answer is Not Affected (feature compiled out) or Score on Root Lock 0.0 (environmental neutralisation). A reachable CVE is not that answer. An in-kernel finding, or a bug that finishes inside an existing grant, stays on the patch date.

This is structurally similar to the backport false positives enterprise Linux teams already manage on RHEL, Rocky, Ubuntu LTS, Debian, and SUSE: a package version string does not prove patch status.

HeartSuite adds a second dimension: configuration and enforcement, not just source version. The correct source of truth is the Kernel Security Transparency page, not upstream version ranges alone.

Bottom line: Treat scanner kernel findings on the Root Lock kernel as candidates for review, not as confirmed vulnerabilities, until you verify against HeartSuite’s published CVE status and config gates.

Correct verification workflow

When a scanner, auditor, or ticket queue reports a kernel CVE on a Root Lock host, follow these steps in order.

Step 1: Identify the installed bundle version

Confirm which kernel is running and which HeartSuite release is installed.

uname -r

On the kernel that ships, uname -r is 6.18.9-hs. The 5.19 line can show a HeartSuite suffix (for example, 5.19.6-HeartSuite-1.0). A distribution string that is neither 6.18.9-hs nor a HeartSuite suffix is the maintenance kernel — see Distro kernel vs Root Lock kernel below; do not apply HeartSuite CVE rules to that boot state.

Record supporting bundle identity for audits:

# Installer bundle checksum (when an update was applied)
sha256sum -c heartsuite-install.sh.sha256

# Kernel config file shipped with the running kernel (for config-gate proof)
ls /boot/config-$(uname -r)

Published SHA-256 manifests accompany distributed bundles (.sha256 files alongside heartsuite-install.sh). Each released Root Lock kernel includes a published SHA-256 of its exact .config file — see the Threat model and evidence-pack-*.txt for the reference hash for your kernel line.

Step 2: Check Kernel Security Transparency for the CVE ID

Open the Kernel Security Transparency page and search for the CVE identifier (for example, CVE-2023-2163).

If the CVE appears in a config gate group (for example, CONFIG_BPF_SYSCALL not set), follow the linked section for the full list of covered CVEs and the technical rationale.

If the CVE does not appear on the transparency page, it may be outside HeartSuite’s assessed scope, newly published, or not yet triaged. Email support@heartsecsuite.com and continue to use distribution errata if you are on the maintenance kernel.

Step 3: Read the published status

Interpret the entry using HeartSuite’s status categories (see the status table below). In practice you will see one of:

For disputed findings, capture a screenshot or export of the CVE row and the linked config-gate section — that is the authoritative rationale.

Step 4: Verify bundle integrity and config gates

For audit-grade evidence, confirm that the running system matches the published artefacts:

Bundle integrity (before install or for change records):

sha256sum -c heartsuite-install.sh.sha256

Config gate on the kernel you boot:

Read the transparency row for that CVE. The build configuration published for the kernel you boot is the proof. The guest file /boot/config-6.18.9-hs is a stub. See Evidence Status.

Optionally reproduce hardening measurements with the published config SHA-256 and the open-source kernel-hardening-checker — full commands in the Threat model.

Step 5: Attach audit documentation

For RFP responses, SOC 2 workpapers, PCI evidence packs, or internal risk acceptance:

1. Export or print the relevant Kernel Security Transparency section for each CVE under review.
2. Attach the Procurement Brief (posture summary and decision context).
3. Attach the Threat model (threat model, residual risks, reproduction steps).
4. Include uname -r output and the bundle SHA-256 verification from Step 1.
5. If the finding is a verified false positive, record it in your scanner exception register with the transparency page URL and config-gate evidence.

Status categories

HeartSuite CVE assessments use explicit categories. Map scanner severities to these before opening a patch ticket.

The word you file is Not affected, Affected, or Fixed, as on Kernel Security Transparency. When the program that reaches the bug has no allowlist entry, that program does not run and the catalog prints 0.0. The catalog also prints 0.0 when the hardware the bug needs is not present. Approving the program makes that row Affected. Not affected is an unset option. An Affected row stays on the patch date.

The transparency page applies four assessment gates in order. That is how the row was checked, not the word you file: (1) compiled in?, (2) outbound control coverage?, (3) does the program that reaches the bug have an allowlist entry?, (4) what can root do under Lockdown? See Scanner Guidance on that page for how a row was checked. Catalog: Compiled-in CVEs, Disabled features.

Scanner configuration guidance

Root Lock is designed to complement vulnerability scanners (Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, Wiz, Greenbone, and similar). Scanners answer “what might be wrong across the fleet.” Root Lock answers “what can actually be exploited on this kernel configuration, and what happens after exploitation under Lockdown.”

Do not use upstream kernel version rules for the Root Lock kernel

• Disable or override policies that map linux_kernel package version to generic NVD CPE ranges for hosts where uname -r is 6.18.9-hs or contains HeartSuite.
• Do not treat “kernel older than upstream fix version” as proof of exploitability on Root Lock.
• Do use the Kernel Security Transparency page as the authoritative CVE status source for Root Lock kernel boots.

Exception process for auditors

Maintain a verified false-positive register aligned with your existing distribution errata exception workflow (RHSA/RLSA on RPM systems, USN on Ubuntu, DSA on Debian, and similar):

Share this page and the transparency CVE section with scanner vendors when requesting custom CPE or rule packs.

Machine-readable feeds (JSON) and OVAL (roadmap)

HeartSuite publishes JSON advisory feeds under /advisories/:

OVAL XML for OpenSCAP is not yet published. Enterprise Linux teams on RPM-based distributions often rely on OVAL definitions (for example, Rocky org.rockylinux.rlsa-9.xml with OpenSCAP; Red Hat and SUSE publish comparable feeds) to reduce false positives. Until HeartSuite OVAL ships:

• Ingest the JSON feeds above where your platform supports them.
• Use the manual workflow in this document for Root Lock kernel hosts and CVEs not covered by feeds.
• Continue using distribution OVAL/errata for maintenance-kernel boots and for non-kernel packages on the same host.

Feed schemas and pipeline detail: Supply Chain and Advisory Feeds.

Distro kernel vs Root Lock kernel

Root Lock installs two kernels via GRUB: the Root Lock kernel (enforcement active) and the original maintenance kernel (a distribution uname, not 6.18.9-hs). CVE evaluation depends on which kernel booted.

During maintenance — package installs, HeartSuite bundle updates, immutable-seal removal — the system often runs on the maintenance kernel. In that window:

• Distribution kernel CVEs and errata apply to the running kernel.
• HeartSuite transparency status for the Root Lock kernel does not describe the kernel that is running.
• Schedule vulnerability scans accordingly: tag scan results with kernel context (Root Lock kernel vs maintenance kernel) to avoid mixing evidence.

After reboot back to the Root Lock kernel, re-evaluate kernel CVEs against the transparency page, not the distro errata alone.

False positive examples

These patterns account for the majority of scanner noise on HeartSuite-protected hosts. For each one, the proof is the pin config — the build configuration published for the kernel you boot — not a grep on the host, because the guest file /boot/config-6.18.9-hs is a stub. See Evidence Status.

BPF-related CVEs when CONFIG_BPF_SYSCALL=n

Scanner logic: NVD lists CVEs in the BPF verifier, BPF maps, or BPF LSM (for example, CVE-2021-20194, CVE-2023-2163, CVE-2023-39191) as affecting kernel ≤ fixed upstream version. Scanner sees 6.18.9-hs and reports Critical/High.

HeartSuite reality: CONFIG_BPF_SYSCALL is unset on 5.19.6 and on the 6.18.9-hs kernel that ships. The bpf() syscall returns ENOSYS. There is no verifier, no program store, and no reachable path — status Not Affected for the BPF syscall interface group. CONFIG_BPF=y stays built in. This covers the syscall entry point.

FUSE-related CVEs

Scanner logic: Flags CVEs in the FUSE filesystem layer (for example, CVE-2023-52504, CVE-2024-41090) based on upstream version.

HeartSuite reality: On the 6.18.9-hs kernel that ships, CONFIG_FUSE_FS=y, so these findings are real and stay on the patch date. They are false positives only on a kernel where CONFIG_FUSE_FS is unset. See the FUSE filesystem group.

The general pattern

Any CVE listed under a config gate section on the transparency page follows the same pattern: if the gate is off, version-based findings are false positives until proven otherwise on the running config.

RHSA / OVAL analogy for enterprise Linux teams

If you manage enterprise Linux — whether Rocky/RHEL (RHSA, OVAL) or Ubuntu/Debian (USN, DSA) — you already verify CVEs with artefacts beyond NVD. On RHEL-family systems, the mapping looks like this:

HeartSuite does not publish RHSA-equivalent errata. The combination of CVE transparency + bundle changelog/release notes + config SHA-256 is the intended audit trail.

For procurement language mapping RHEL expectations to HeartSuite deliverables, see the Enterprise Adoption Guide and Kernel Support Policy.

Audit evidence package checklist

Attach the following to RFP responses, due-diligence questionnaires, and auditor workpapers for kernel CVE posture on Root Lock:

• Host context: uname -r, Lockdown state (Dashboard indicator or status.json), scan date
• Kernel line: Root Lock kernel (transparency page) vs maintenance kernel (distro errata) — explicit label
• Procurement Brief — comparison table and buyer decision guide
• Threat model — threat model, measured scores, residual risks, reproduction commands
• Kernel Security Transparency exports — one section per disputed or sampled CVE
• Config-gate evidence — the transparency row for that CVE. On the 6.18.9-hs kernel that ships, CONFIG_FUSE_FS=y, so FUSE findings stay on the patch date. See FUSE-related CVEs.
• Bundle integrity — sha256sum -c heartsuite-install.sh.sha256 output (or subscription delivery record)
• Config hash match — the published hash for the kernel you boot, in Evidence Status. The guest file /boot/config-6.18.9-hs is a stub.
• False-positive register — scanner exception rows with transparency links (if applicable)
• Maintenance records — dates when the maintenance kernel was used; distro patches applied during those windows (Updating Root Lock, Protecting During Maintenance)
• Compensating controls — Lockdown allowlist policy, SIEM/syslog integration (Alert Settings)

Nothing in this package requires trusting opaque vendor claims for measured posture: config hashes and checker outputs are reproducible on the customer side.

Related reading

• Kernel Support Policy — Patch targets, notification channels, version-string semantics
• Supply Chain and Advisory Feeds — Published JSON feeds (CONFIG SBOM, OSV, CycloneDX); OVAL and signing roadmap
• Distro Compatibility Matrix — Validated distributions and RHEL-family guidance
• Kernel Security Transparency — per-CVE status, Score on Root Lock, config gates, scanner guidance
• Procurement Brief — hardening comparison and adoption decision guide
• Threat model — threat model, residual risks, independent reproduction
• Enterprise Adoption Guide — CVE handling ownership, supply chain, fleet operations
• Updating Root Lock — bundle application and SHA-256 verification
• Lockdown — Root Lock kernel vs maintenance kernel semantics
• How Root Lock Compares — vulnerability scanners as complementary controls
• Comparison Matrix — measured attack-surface scores (5.19.6 line)

This page is intentionally scanner- and auditor-facing. All verification steps reference publicly reproducible artefacts or the open CVE transparency data. Last updated: 2026-06-22.

6 - How to verify the kernel you downloaded

Overview: What supply-chain artefacts HeartSuite publishes today (SHA-256 bundle integrity, CONFIG-gate SBOM, OSV, CycloneDX) and what remains on the roadmap (GPG/cosign signing, OVAL).

Audience: Procurement, vendor risk, GRC, and platform security teams mapping HeartSuite deliverables to supply-chain questionnaires, SOC 2 / ISO evidence requests, and enterprise Linux vulnerability-management programs.

Related reading: Kernel Support Policy, Enterprise Adoption Guide, CVE Hygiene for Scanners, Evidence Status, Threat model, Updating Root Lock.

What this page covers

This page states what HeartSuite publishes today for Root Lock kernel supply-chain verification and what is on the roadmap.

It is the single reference for:

• Bundle integrity — SHA-256 checksums now; GPG and cosign signing planned.
• Bundle manifests — version identifiers, addressed CVE list, and checksum references shipped with coordinated releases.
• Reproducible configuration evidence — published .config SHA-256 per supported Root Lock kernel stream.
• Machine-readable advisories — Published JSON feeds under /advisories/ (catalogue: hs-advisory-catalog/v1). For the current release (hs-v1.6.4-kernel-6.18.9, gate_status: PASS): CONFIG-gate Not-Affected SBOM, OSV (279 entries at /advisories/osv.json), and CycloneDX bundle SBOM. OVAL XML for OpenSCAP remains on the roadmap.
• SBOM — CycloneDX bundle SBOM published at /advisories/sbom.cyclonedx.json; SPDX dual-format support will be stated at GA.

For patch targets, notification channels, and support boundaries, see the Kernel Support Policy. For fleet deployment and buyer-facing limitations, see the Enterprise Adoption Guide.

Summary: today versus roadmap

HeartSuite does not commit to delivery dates for roadmap items on this page. When an artefact reaches general availability, this page and the Kernel Support Policy will be updated and customers will be notified through subscription email and release notes.

What you can verify today

Installer and bundle integrity (SHA-256)

Coordinated HeartSuite updates ship as a self-extracting heartsuite-install.sh bundle. Each distribution includes a companion heartsuite-install.sh.sha256 file.

Before execution, verify integrity:

sha256sum -c heartsuite-install.sh.sha256

Expected output: heartsuite-install.sh: OK

This is the only generally available cryptographic integrity check for bundles today. It confirms the file you received matches the checksum HeartSuite published for that release, but it does not by itself prove publisher identity, which is why GPG and cosign signing are on the roadmap (see below).

Full install procedure and maintenance-window context: Updating Root Lock.

Reproducible kernel configuration (SHA-256 per stream)

Every released Root Lock kernel stream publishes the SHA-256 hash of the exact kernel .config used for that build. This hash is the anchor for independent hardening verification:

• Compare the published hash to the pin payload .config, not the installed /boot/config-$(uname -r) on 6.18.9-hs, because that file is an 11-line initramfs stub (CONFIG_IKCONFIG is off). Hashes and commands: Threat model, Evidence Status.
• Re-run the open-source kernel-hardening-checker against that pin config to reproduce attack-surface and exploit-resistance scores.
• Cross-check stream-specific raw output in evidence-pack-*.txt artefacts referenced from the comparison and auditor pages.

Config hashes are per stream (for example, 6.18 primary LTS and legacy 5.19), not a single global value. Publication status per stream is tracked in Evidence Status.

This model is intentionally reproducible on the customer side — auditors do not need to trust opaque scoring claims if they verify the hash and re-run the checker.

Kernel Security Transparency (CVE rationale)

Per-CVE status, config gates, and Score on Root Lock are published on the Kernel Security Transparency page. This is the authoritative human-readable advisory layer for the Root Lock kernel.

Machine-readable mirrors:

Feeds are published on this documentation site when HeartSuite cuts an annotated hs-v* kernel release. Publication is automated from HeartSuite’s internal release pipeline; customers do not need access to private build repositories to consume the feeds.

Root Lock kernel source code (GPL)

HeartSuite distributes the Root Lock kernel as binaries in the coordinated heartsuite-install.sh bundle. Portions of the Root Lock kernel are subject to the GNU General Public License.

HeartSuite does not maintain a public kernel source repository at this time. Corresponding source code for the Root Lock kernel build you are running is available on written request under GPL obligations.

Email support@heartsecsuite.com and include:

• Output of uname -r (fielded pin: 6.18.9-hs) and file on vmlinuz (expect #43)
• HeartSuite product version (for example, v1.6.4)
• Release tag or heartsuite-install.sh.sha256 reference if known

HeartSuite will provide source matching that build. Independent verification of kernel configuration does not require source access — use the published .config SHA-256 and reproduction steps in the Threat model.

Subscription notification

Security advisories, bundle availability, and stream-deprecation notices go to contacts registered on the subscription (email), supplemented by release notes on this site. See Customer notification in the Kernel Support Policy.

Bundle manifest

Each coordinated release is accompanied by a bundle manifest (shipped with the bundle or referenced in release documentation). Manifests are the release-level changelog for procurement and vulnerability-management traceability.

Published fields (today)

Manifests do not replace the Kernel Security Transparency page for reachability analysis. A CVE omitted from the “addressed” list may still be Not Affected on Root Lock kernels because the vulnerable subsystem was never compiled in.

Planned manifest extensions

When signing and SBOM artefacts ship, manifests will add non-breaking references:

• GPG key fingerprint and signature file location
• Cosign bundle signature digest (OCI/sigstore-style provenance)
• SBOM document URI and format (SPDX or CycloneDX)

Existing SHA-256 verification remains valid for customers who have not yet adopted the new artefacts.

Roadmap: GPG and cosign signed bundles

Today: Integrity is SHA-256 only, which detects accidental corruption or tampering in transit when you verify against the published checksum before execution.

Planned:

Current position:

• This site publishes no GPG public key or cosign policy yet.
• SHA-256 verification remains the install baseline until signing is generally available, so customers are not required to use signing before install.
• Signing adds publisher authenticity and pipeline integration; the Root Lock kernel’s CVE reachability model and Lockdown semantics stay the same.

Teams with mandatory code-signing policies should treat SHA-256 + config-hash verification as the current interim control and email support@heartsecsuite.com for questionnaire language until GPG/cosign GA.

Published advisory feeds (Root Lock kernel)

Enterprise Linux teams often use OVAL definitions with OpenSCAP, or OSV entries in broader SCA tooling, to reduce false positives from raw NVD version matching.

Published today for release tag hs-v1.6.4-kernel-6.18.9 (gate_status: PASS in the catalogue), as JSON under /advisories/ (absolute base https://docs.heartsecsuite.com/advisories/):

• index.json — Feed catalogue (hs-advisory-catalog/v1) with release tag, HeartSuite version, kernel base, and per-feed published flags.
• hs-cve-config-sbom.json — CONFIG-gate Not-Affected manifest (hs-cve-config-sbom/v1) produced by the CVE↔CONFIG crosswalk gate in Root Lock CI.
• osv.json — 279 OSV entries derived from the CONFIG SBOM and transparency page (alias of osv/all.json).
• sbom.cyclonedx.json — CycloneDX bill of materials for the coordinated bundle.

Not yet published: OVAL XML for OpenSCAP. Teams that require OVAL today should ingest the published CONFIG SBOM and OSV feeds, plus the manual workflow in CVE Hygiene for Scanners.

Scanners that compare uname -r to upstream “fixed in” versions will still generate noise on Root Lock kernel boots until your toolchain consumes these feeds or the manual hygiene workflow.

What the feeds encode

The feeds encode logic that version strings alone cannot express:

The feeds do not replicate RHSA numbering or distribution errata semantics, because HeartSuite remediation is expressed through coordinated bundles and transparency documentation rather than per-CVE RPM errata on the Root Lock kernel binary.

Automation workflow

1. Pull the catalogue: curl -fsS https://docs.heartsecsuite.com/advisories/index.json
2. Ingest hs-cve-config-sbom.json and osv.json into your vulnerability-management platform.
3. For CVEs not covered by machine-readable entries, use CVE Hygiene for Scanners:
   • Confirm boot context: fielded Root Lock kernel is 6.18.9-hs (see Evidence Status). That string has no HeartSuite substring, so its absence does not mean you are on the maintenance kernel.
   • Look up the CVE on Kernel Security Transparency.
   • Verify compiled-out claims against the pin payload config, because the installed /boot/config-6.18.9-hs is a stub.
   • Record exceptions with pin identity, config evidence, and a transparency link.

Continue using distribution OVAL/errata for maintenance-kernel boots and for non-kernel packages.

SBOM (CycloneDX published; SPDX at GA)

Published: CycloneDX bundle SBOM at /advisories/sbom.cyclonedx.json for hs-v1.6.4-kernel-6.18.9 (published: true on the cyclonedx-sbom entry in /advisories/index.json).

Scope (CycloneDX generator):

• Coordinated bundle contents — Root Lock kernel binary, userspace daemon/Dashboard/tools, and installer dependencies relevant to the enforcement stack.
• Linkage: Bundle manifest references the SBOM URL; catalogue records release tag and HeartSuite version.

Roadmap: SPDX and/or dual SPDX+CycloneDX support will be stated at GA if offered.

Complementary artefacts (always available):

• Published kernel .config SHA-256 and evidence-pack-*.txt for reproducible hardening measurement (5.19.6 legacy pack; 6.18.9-hs #43 pack published 2026-10-02; the 18 August pack is build #37 — see Evidence Status)
• CONFIG-gate SBOM at /advisories/hs-cve-config-sbom.json
• Bundle SHA-256 manifests
• CVE transparency and bundle manifest CVE lists

SBOM publication improves dependency inventory and procurement automation; it does not replace config-gate CVE analysis for the Root Lock kernel.

Mapping to common procurement questions

What HeartSuite does not provide (supply-chain scope)

To set expectations for RFPs and vendor-risk assessments:

If a control framework requires GA OVAL feeds or GPG/cosign signing before production approval, plan for the interim artefacts in this document. Document compensating controls (published JSON feeds, manual CVE hygiene, config-hash verification, bundle manifest retention) until roadmap items ship.

Related reading

• Kernel Support Policy — Patch targets, bundle delivery, notification, version strings, and “does not provide” boundaries.
• Evidence Status — 5.19.6 vs 6.18.9 publication status.
• Enterprise Adoption Guide — Fleet operations, supply-chain summary, Secure Boot status, and honest limitations.
• CVE Hygiene for Scanners — Root Lock kernel CVE verification; ingest published OSV/CONFIG SBOM feeds; OVAL interim workflow.
• Threat model — Threat model, reproduction commands, evidence packs.
• Distro Compatibility Matrix — Stream and distribution validation.
• Kernel Security Transparency — Per-CVE status and config gates.
• Updating Root Lock — Bundle verification and update procedure.

This page is procurement- and GRC-facing. Availability statements reflect public deliverables as of the last-updated date; roadmap items have no committed GA dates unless separately agreed in writing. Last updated: 2026-06-23.

7 - Which kernel evidence is published today

Subject: Root Lock kernel evidence
Kernel that ships: 6.18.9-hs build #43, packaging 6.18.9-HeartSuite-3. The BPF syscall is off.
Checker pack for that binary: evidence-pack-6.18.9.txt (2026-10-02). Config and checker only. No guest boot.
18 August 2026 pack: build #37, evidence-pack-6.18.9-2026-08-18.txt. That pack includes the Debian 12 guest boot.
Legacy stream: kernel 5.19.6 (maintenance-only; see Kernel Support Policy)

Summary

5.19.6 scores are legacy. Build #37 is the 18 August measurement. Build #43 is the kernel that ships.

What the build #43 pack contains

• Identity — file #43, vmlinuz SHA-256 f2e47498…, packaging config SHA-256 d6a08a04… in evidence-pack-6.18.9.txt
• Automated scores — checker e870d01, run 2026-10-02: overall 153/259 (59.1%), attack-surface 62/131 (47.3%), exploit-resistance 78/110 (70.9%)
• Runtime — not repeated. The Debian 12 guest boot is the build #37 pack.
• What moved since #37 — CONFIG_BPF_SYSCALL, CONFIG_KEXEC, CONFIG_KEXEC_FILE, CONFIG_CRASH_DUMP, and CONFIG_PROC_VMCORE are unset. CONFIG_IO_URING stays y.
• Buyer pages — Procurement Brief, Threat model, and the 6.18.9 matrix use these checker totals. Arch and vanilla columns stay the 18 August rows.

What the 18 August 2026 pack contains

• Identity — uname 6.18.9-hs, file #37, vmlinuz SHA-256 1b44fffb…, config SHA-256 3cd18247… in evidence-pack-6.18.9-2026-08-18.txt
• Automated scores — checker e870d01: overall 148/259 (57.1%), attack-surface 57/131 (43.5%), exploit-resistance 78/110 (70.9%)
• Runtime — Debian 12 guest: LSM lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm, Root Lock activation at t+4s. Procurement, the threat model, and the 6.18.9 matrix cite this guest when they name a booted LSM list.

Known limits of this publication

• Era-matched Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are in the pack.
• Guest /boot/config-6.18.9-hs is an 11-line initramfs stub, and CONFIG_IKCONFIG is off, so the running kernel does not export its config either. Analysis therefore uses the pin payload config, whose SHA-256 is recorded in the pack.
• This pack is the 18 August 2026 run. It is not the kernel that ships.

What remains from 5.19.6

The 5.19.6 pack is unchanged and still reproducible (checker b9b83a0, SHA d67caa6… / fa227f1d…). Do not add 5.19.6 percentages to a 6.18.9-hs deployment report.

For procurement and audit teams

Evaluating a 6.18.9-hs deployment today

• Use evidence-pack-6.18.9.txt for build #43 (config and checker). Use evidence-pack-6.18.9-2026-08-18.txt when you need the guest boot. Threat model: auditor brief.
• Confirm uname -r is 6.18.9-hs. The uname -r string does not contain the word HeartSuite, so its absence is not a sign that the maintenance kernel is running.
• On the kernel that ships, the BPF syscall is off, so there is no eBPF program to load. A finding stays on the patch date when that option is set on the kernel you boot.

Evaluating a 5.19.6 legacy fleet

• Use evidence-pack-5.19.6.txt. Plan migration per the support policy.

Related pages

• Hardening matrix for kernel 6.18.9
• Hardening scores: 5.19.6
• Enterprise Adoption Guide

8 - Hardening matrix for kernel 6.18.9

This page compares hardening-checker scores. It is not the list of which kernel CVEs are Not affected, Affected, or Fixed. That list is Kernel Security Transparency. The 18 August file is build #37, and on that build the BPF syscall is on. The kernel that ships is 6.18.9-hs build #43, and on that build the BPF syscall is off.

Subject: kernel that ships, 6.18.9-hs build #43 (packaging 6.18.9-HeartSuite-3).
uname -r: 6.18.9-hs
Config SHA-256 (packaging config): d6a08a04f4d6734adbafac431c3ebe46d339a495d907f1c6c569959321cc3684
vmlinuz SHA-256: f2e4749856f56cde87f9bcc887620f2d9b0aa2066756e4d3501326660b926c92
Tool: kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac, run 2026-10-02
Source file: evidence-pack-6.18.9.txt
Guest boot: the Debian 12 boot is build #37, in evidence-pack-6.18.9-2026-08-18.txt. It was not repeated for build #43.
Legacy: Hardening scores: 5.19.6, evidence-pack-5.19.6.txt

Hash the packaging config. Guest /boot/config-6.18.9-hs is an 11-line initramfs stub, and CONFIG_IKCONFIG is off.

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are the 18 August 2026 rows. They were not re-run on 2026-10-02. The checker commit is the same, so the columns compare.

Part 1 — Measured comparison

Build #37 on the same checker was 148/259 (57.1%) overall and 57/131 (43.5%) attack-surface. Exploit-resistance stayed 78/110. Five attack-surface checks moved to OK on #43: CONFIG_BPF_SYSCALL, CONFIG_KEXEC, CONFIG_KEXEC_FILE, CONFIG_CRASH_DUMP, and CONFIG_PROC_VMCORE. CONFIG_IO_URING stays y.

Reading the table

• Attack-surface = dangerous features disabled. Higher = more things off.
• Exploit-resistance = defensive mitigations against memory bugs. Higher = harder to exploit.
• These axes are largely independent.
• Do not compare these percentages to the 5.19.6 pack, because its checker commit (b9b83a0) uses different item counts (132 / 109).

What this shows

HS 6.18.9-hs #43 trails on attack-surface (47.3% vs era-matched Arch 58.0% and vanilla 6.18.9 defconfig 67.2%).

HS 6.18.9-hs #43 sits above vanilla 6.18.9 defconfig on exploit-resistance (70.9% vs 50.9%) and below era-matched Arch 6.18.16 hardened (83.6%).

The overall count ties vanilla 6.18.9 defconfig at 153/259. The mix differs: #43 disables fewer features and turns on more exploit-resistance options.

Exploit-resistance mitigations — measured

Part 2 — Qualitative orientation (cross-project)

Part 3 — LSM stack

The #43 packaging config records:

CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf,ipe"

CONFIG_SECURITY_SELINUX=y and CONFIG_DEFAULT_SECURITY_SELINUX is unset. CONFIG_BPF_SYSCALL is unset, so there is no eBPF program to load. That string is the config list. It is not a reading of /sys/kernel/security/lsm from a booted #43 guest.

The Debian 12 guest boot on 2026-08-18 is build #37:

Part 4 — CPU mitigations (6.18 naming)

Summary

† Different checker commit and item counts — directional only.

For the 5.19.6 dataset see Hardening scores: 5.19.6. Raw notes: evidence-pack-6.18.9.txt. The 18 August guest boot: evidence-pack-6.18.9-2026-08-18.txt. Publication status: Evidence Status.

9 - Hardening scores: 5.19.6 against the field

Subject: Root Lock by HeartSuite, kernel 5.19.6
Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: kernel-hardening-checker commit b9b83a0, run 2026-05-19
Source file: evidence-pack-5.19.6.txt

Note: 5.19.6 is the legacy kernel line, installed only on Debian 11 and Ubuntu 20.04. New installs on every other supported distribution run 6.18.9-hs, whose posture is in Hardening matrix for kernel 6.18.9.

Part 1 — Measured comparison (same kernel era)

All three configs below are built from the 5.19.x kernel tree. Checker scores are directly comparable — same Kconfig namespace, same option universe.

Reading the table

• Attack-surface measures how many dangerous kernel features are disabled. Higher = more things turned off.
• Exploit-resistance measures how many defensive mitigations against memory bugs are enabled. Higher = harder to exploit.
• These two axes are largely independent and optimized for different threat models.

What this shows

HS leads on attack-surface (91 vs 77 vs 90): it disables BPF_SYSCALL, FUSE_FS, OVERLAY_FS, SECURITY_APPARMOR, SECURITY_TOMOYO, and USER_NS — all of which Arch linux-hardened keeps enabled for its general-purpose user base.

Arch linux-hardened leads on exploit-resistance (69 vs 31): it enables HARDENED_USERCOPY, FORTIFY_SOURCE, INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON, SLAB_FREELIST_RANDOM, and MODULE_SIG — all absent in HS 5.19.6.

Vanilla defconfig is the baseline: it does about as well as HS on attack-surface (most things aren’t enabled by default) but even worse on exploit-resistance.

Bypass-primitive disables — side by side

HS 5.19.6 disables five of the eight options and Arch linux-hardened disables a different three, so neither disables all eight.

Exploit-resistance mitigations — side by side

Part 2 — Qualitative orientation (cross-project)

These projects were not scored with the checker in this analysis — either because their configs were unavailable for the 5.19 era, because they are paywalled, or because a meaningful config was not locatable. Characterizations are drawn from each project’s public documentation and design goals.

Notes on the qualitative table:

• “Bypass Prevention” = removal of subsystems that can circumvent MAC/LSM enforcement.
• “Exploit Resistance” = mitigations against kernel memory bugs (heap, stack, pointer corruption).
• NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance — it is no longer an active project. The bundled config in kernel-hardening-checker (6.12.50-hardened1) is a historical snapshot.
• CLIP OS: the public CLIP OS project is archived. The ANSSI team published their kernel configs; they are accessible at the archived CLIP OS documentation.
• grsecurity requires a paid subscription; their config is not publicly available for automated analysis.
• GrapheneOS targets Android hardware (aarch64); its hardening is not directly applicable to x86 server deployments.

Part 3 — LSM stack (measured)

Part 4 — CPU mitigations (5.19.6 naming)

5.19.6 uses pre-6.1 option names, and the checker looks for the 6.1+ CONFIG_MITIGATION_* names, so it reports these as FAIL even though the mitigations are present:

Summary

10 - What a red team should test on this kernel

Subject: Root Lock by HeartSuite — 6.18.9-hs build #43 (packaging 6.18.9-HeartSuite-3). 5.19.6 is the legacy k5 line.
Evidence status: Checker scores for the kernel that ships are in evidence-pack-6.18.9.txt (2026-10-02). The Debian 12 guest boot is build #37, evidence-pack-6.18.9-2026-08-18.txt. The 5.19.6 pack remains the measured record of that legacy line.
Primary stream: Hardening matrix for kernel 6.18.9
Legacy stream: Config SHA-256 d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc — measured 2026-05-19, checker b9b83a0 — comparison matrix, evidence-pack-5.19.6.txt

On the kernel that ships, the BPF syscall is off, CONFIG_IO_URING=y, and CONFIG_KEXEC is unset.

Threat model

Root Lock targets a process on the protected system attempting to bypass VFS-level enforcement. The BPF syscall is off on the 6.18.9-hs kernel that ships, so there is no eBPF program to load. The countermeasure is the allowlist and Lockdown.

What the measurements show (build #43, checker run 2026-10-02)

Tool: kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac, 2026-10-02, against packaging config SHA-256 d6a08a04f4d6734adbafac431c3ebe46d339a495d907f1c6c569959321cc3684.

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are the era-matched 6.18.x peers from the 18 August run of the same checker (no 6.18.9-hardened in the Arch archive). Keep these percentages off the 5.19.6 pack, because its checker commit (b9b83a0) counts a different set of items.

Attack-surface reduction

Automated score: 62/131 (47.3%)
Era-matched Arch linux-hardened 6.18.16: 76/131 (58.0%). Era-matched vanilla 6.18.9 defconfig: 88/131 (67.2%). KSPP x86-64 intent: 131/131 (100%).

Build #43 trails both era-matched peers on this axis. Five checks moved to OK since build #37: CONFIG_BPF_SYSCALL, CONFIG_KEXEC, CONFIG_KEXEC_FILE, CONFIG_CRASH_DUMP, and CONFIG_PROC_VMCORE.

Exploit-resistance (KSPP-style mitigations)

Automated score: 78/110 (70.9%)
Era-matched Arch linux-hardened 6.18.16: 92/110 (83.6%). Era-matched vanilla 6.18.9 defconfig: 56/110 (50.9%). KSPP: 93/110 (84.5%).

This pin scores above vanilla 6.18.9 defconfig on this axis. Present: INIT_ON_ALLOC_DEFAULT_ON, HARDENED_USERCOPY, FORTIFY_SOURCE, SLAB_FREELIST_RANDOM, SLAB_FREELIST_HARDENED, KFENCE, MODULE_SIG. Still missing or unforced: INIT_ON_FREE_DEFAULT_ON, MODULE_SIG_FORCE, RANDSTRUCT_FULL, KSTACK_ERASE, KFENCE_SAMPLE_INTERVAL=0.

Overall checker: 153/259 (59.1%).

Runtime (Debian 12 guest, 2026-08-18, build #37)

This guest boot was not repeated for build #43. Debian 12 lab guest, uname -r 6.18.9-hs, file #37, vmlinuz SHA-256 1b44fffb9b570497f19f4c68e170602b542bc84bfe9f49d936c123dc59f5db8a.

• /sys/kernel/security/lsm = lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm
• No selinuxfs. /proc/self/attr/current = unconfined
• dmesg: LSM list above at t+0.05s; activating Heartsuite service / monitor ON at t+4s
• Guest /boot/config-6.18.9-hs is an 11-line initramfs RD stub, not the build config. Hash the pin payload config, not that file.

Residual risks

1. Kernel memory corruption / exploitation
Self-protection scores 78/110, well above the vanilla baseline that 5.19.6 sat near, but heap and CFI gaps remain: no INIT_ON_FREE_DEFAULT_ON, no KSTACK_ERASE, no RANDSTRUCT_FULL, KFENCE sample interval 0, IOMMU default is lazy. An attacker who reaches a reliable in-kernel primitive still has those gaps.

2. Competing LSMs are live
The 5.19.6 description (Root Lock as the sole enforcing MAC, SELinux permissive, no securityfs) does not hold on this pin. AppArmor, TOMOYO, Yama, Landlock, BPF LSM, IMA, and EVM initialize. Red-team work must include stacked-LSM interaction (policy denials, IMA, AppArmor profiles), not only Root Lock.

3. MODULE_SIG is on; MODULE_SIG_FORCE is not
CONFIG_MODULE_SIG=y and CONFIG_MODULE_SIG_FORCE is not set, so the kernel does not require a valid signature on every module. Instead, current installs close module loading outright with a latch: a kernel setting that, once switched on, stays on until the next reboot. heartsuite-kernel-latch.service runs early in every Root Lock kernel boot, Setup Mode included, before the network is configured and before sshd starts. It loads the netfilter modules the firewall needs, then sets kernel.modules_disabled=1, and kernel.kexec_load_disabled=1 where the kernel has that setting. The module setting cannot be cleared until reboot: init_module, finit_module, and delete_module are refused, and a later modprobe stays refused. The latch script does not unload modules already loaded by initramfs, udev, the netfilter preload, or binfmt_misc. Code built in with =y was never a module. HS_lockdown.sh writes both settings again, where the node exists, in case the latch service is masked. OpenRC systems have no latch service and get those writes only when Lockdown is applied.

Measured evidence predates the latch. The build #37 guest (18 August 2026) booted without it and read both settings as 0. The build #43 pack did not boot a guest, so neither setting was measured on #43. On #43, CONFIG_KEXEC is unset, so kexec_load_disabled does not exist there.

4. Can root unseal the allowlist or turn enforcement off?
By design, root has no intended path to lift the allowlist seal or turn enforcement off, because there is no agent to kill: the seal and the control paths are enforced in the kernel. Test that contract rather than reading it off the architecture diagram, and confirm on the kernel that ships (6.18.9-hs) that additional syscalls and related attributes are gated as well.

The checker percentages measure only the published .config, so read them together with this residual-risk list during architecture review.

5. Allowlist breadth after learning
Setup Mode records what programs do, and you approve the resulting allowlist entries. Any entry wider than the workload needs stays in force after Lockdown.

6. Intentional maintenance and console recovery path
Supported recovery of a sealed allowlist requires booting the maintenance kernel and using Dashboard Maintenance to lift immutability flags. That path requires physical or serial-console access — keyboard and monitor, serial port, or cloud provider serial console.

7. Confused deputy among allowlisted programs
Enforcement is per program identity, so an allowlisted program with broad grants can still be abused within those grants.

8. Portable open flags and size mutation under a read grant
By default Root Lock keeps the standard Linux behaviour of O_RDONLY|O_TRUNC, so a program with a read grant can still truncate a file when DAC write permission allows it.

How to reproduce these measurements

git clone https://github.com/a13xp0p0v/kernel-hardening-checker /tmp/khc
git -C /tmp/khc checkout e870d0141259f875d3d1b54fef49dec7074e4cac

# Use the pin payload config — NOT guest /boot/config-6.18.9-hs (11-line stub)
sha256sum config-6.18.9-hs
# Expected: d6a08a04f4d6734adbafac431c3ebe46d339a495d907f1c6c569959321cc3684

python3 /tmp/khc/bin/kernel-hardening-checker -c config-6.18.9-hs
# Expected summary: OK - 153 / FAIL - 106

Bypass-primitive greps on the #43 packaging config. CONFIG_BPF_SYSCALL, CONFIG_KEXEC, and CONFIG_KEXEC_FILE are unset, so they do not match a = line. CONFIG_IO_URING=y, CONFIG_FUSE_FS=y, CONFIG_USER_NS=y, CONFIG_SECURITY_APPARMOR=y, CONFIG_SECURITY_TOMOYO=y, and CONFIG_OVERLAY_FS=m.

grep -E "CONFIG_(BPF_SYSCALL|IO_URING|FUSE_FS|OVERLAY_FS|SECURITY_APPARMOR|SECURITY_TOMOYO|KEXEC|KEXEC_FILE|USER_NS)" \
  config-6.18.9-hs

The /sys/kernel/security/lsm reading below is the build #37 guest from 2026-08-18. A #43 guest boot was not recorded.

uname -r
# 6.18.9-hs
python3 -c "print(open('/sys/kernel/security/lsm').read())"
# lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm

Full raw notes: evidence-pack-6.18.9.txt. Guest boot: evidence-pack-6.18.9-2026-08-18.txt.

11 - SELinux, AppArmor, TOMOYO — a different job

Subject: Archived kernel 5.19.6. The kernel that ships is 6.18.9-hs, and on that kernel the BPF syscall is off.
Audience: Security engineers familiar with SELinux, AppArmor, or TOMOYO reading the archived 5.19.6 comparison.

The core distinction

This page is the archived 5.19.6 kernel. It is not the kernel that ships.

SELinux, AppArmor, and TOMOYO all answer the same question: given that a kernel feature is present, what should a process be allowed to do with it?

On 5.19.6, the Root Lock column records which of those features that kernel left unset.

Comparison table

Bypass primitives: open vs closed

The table below lists the kernel-level bypass vectors most relevant to MAC enforcement. “Closed” means the kernel option is disabled — the attack vector does not exist on the system. “Open” means the feature is present and policy must account for it.

An attacker who can reach any “Open” primitive has a path to bypass LSM enforcement regardless of how well the policy is written. On 5.19.6, HeartSuite closes all four vectors above at the kernel config level.

When SELinux, AppArmor, or TOMOYO is the right choice

Root Lock is not a general-purpose MAC replacement. Choose SELinux, AppArmor, or TOMOYO when:

• You are running a general-purpose multi-user system where diverse workloads need fine-grained per-process policy.
• You require MLS / MCS (Multi-Level Security / Multi-Category Security) for labeled data separation.
• You need container runtime support that depends on USER_NS or overlayfs (Kubernetes, Docker, Podman, LXC).
• Your compliance framework mandates a specific named LSM (e.g., STIG-mandated SELinux).
• You need to audit permitted accesses, not just denials. Root Lock logs every denied file access, socket connection, and sandbox violation with the specific program path and target resource. Successful accesses are not logged. SELinux and TOMOYO can record both. If a full allowed-access trail is also required, SELinux can run alongside Root Lock on supported deployments — see Co-existence.

When Root Lock is the right choice

Choose Root Lock when:

• You are deploying a single-purpose appliance running one or a small set of known workloads.
• Your threat model centers on containment escape — a compromised application attempting to break out of its enforcement boundary.
• You want zero policy surface — no policy file, no audit2allow, no profile to misconfigure.
• On kernel 5.19.6, BPF tooling, container runtimes, FUSE mounts, and user namespaces are not part of that kernel’s attack surface — they are absent from the 5.19.6 kernel, not restricted by policy.
• You want a violation-focused audit trail: every denied file access, network connection, and sandbox violation is logged with the specific program path and target resource. In Setup Mode, would-be denials are logged and permitted simultaneously. That gives full visibility into the policy surface without blocking anything.
• You want independent verifiability: the kernel config SHA-256 is published and measurements are reproducible with an open-source tool.

Co-existence

On kernel 5.19.6, Root Lock does not stack with AppArmor or TOMOYO. Both are kernel-disabled on 5.19.6 (CONFIG_SECURITY_APPARMOR=n, CONFIG_SECURITY_TOMOYO=n).

SELinux can run alongside Root Lock. Root Lock’s VFS hooks fire before the LSM chain (security_path_*() calls). The ordering means:

• If Root Lock denies an operation → the SELinux hook is never reached. Root Lock is the first and final authority on that call.
• If Root Lock allows an operation → SELinux can still deny it. SELinux can only add restrictions to what Root Lock allows, never grant access Root Lock denies.

This ordering is intentional: whatever SELinux mode and policy the deployment OS configures, the stacking is additive, not conflicting, and Root Lock enforcement cannot be bypassed via the SELinux layer.

RHEL operational note: As with any new kernel module on RHEL, a targeted SELinux policy entry may be needed for Root Lock’s specific operations. If AVC denials appear, ausearch -m AVC -ts recent | audit2why identifies them and audit2allow generates the targeted module. Those denials come from SELinux after Root Lock has already allowed the operation, so Root Lock enforcement is unaffected.

Further reading

• Comparison Matrix — Measured kernel-hardening-checker scores: HeartSuite vs Arch linux-hardened vs vanilla defconfig.
• Threat model — Residual risks, threat model, and self-reproduction instructions.
• Procurement Brief — Decision guide for buyers choosing between hardened kernel options.

12 - Kernel hardening in plain language

Kernel: Root Lock by HeartSuite 5.19.6. Config hash: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc. Measured: 2026-05-19.

Note: 5.19.6 is the legacy k5 line, kept for lab re-proof on Debian 11 and Ubuntu 20.04. New installs on the supported distributions run 6.18.9-hs, whose posture is in Hardening matrix for kernel 6.18.9.

On a run of the open-source kernel-hardening-checker config linter — the same tool Linux kernel security researchers use — the Root Lock 5.19.6 kernel outperforms Arch linux-hardened on attack-surface measures.

Scores, compared on the same 5.19.x kernel generation so they are directly equivalent: 91 out of 132 checks passed by Root Lock versus 77 out of 132 for Arch linux-hardened.

Where Root Lock is not strongest: Exploit resistance.

When a kernel vulnerability is discovered — a memory bug, a logic flaw — certain protection techniques make it much harder to turn that bug into a working attack. The Root Lock kernel does not include most of those techniques, so it scores 31 out of 109 checks on this measure. The era-matched Arch linux-hardened kernel (same kernel generation) scores 69 out of 109 on the same tool.

Root Lock is designed to stop attacks from bypassing its controls rather than to harden the kernel against every possible vulnerability.

The configuration is publicly verifiable: the SHA-256 hash of the kernel configuration file is published, so any qualified security team can reproduce the measurements above with publicly available tools.

For fact-checkers: All numbers in this summary derive from evidence-pack-5.19.6.txt and Hardening scores: 5.19.6 in this section. Tool: kernel-hardening-checker at commit b9b83a0. Every claim can be independently reproduced.