A smaller kernel, not a thicker agent

• 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 by HeartSuite kernel configuration choices against community hardened kernels and the KSPP benchmark.

Subject: Fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37). 5.19.6 is the legacy measured stream.
Evidence: evidence-pack-6.18.9.txt (2026-08-18, checker e870d01). Legacy: 5.19.6 matrix, evidence-pack-5.19.6.txt.

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

All numbers below are outputs of kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac applied to the #37 pin config (SHA-256 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9) and to configs bundled with that checker.

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 (checker b9b83a0).

This page measures the fielded pin. It does not describe a derived cut that disables IO_URING or KEXEC.

At a glance (fielded 6.18.9-hs #37)

* 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), 0 modules loaded / 9 .ko. See the 5.19.6 matrix.

What this pin is and is not

On 5.19.6, Root Lock compiled out BPF, user namespaces, FUSE, OverlayFS, AppArmor, and TOMOYO, and sat near vanilla on exploit-resistance.

On fielded 6.18.9-hs #37 that story is inverted:

• Bypass primitives above are compiled in (OVERLAY_FS=m).
• Live LSM on the measured guest: lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm.
• Exploit-resistance options INIT_ON_ALLOC_DEFAULT_ON, HARDENED_USERCOPY, FORTIFY_SOURCE, SLAB_FREELIST_RANDOM / _HARDENED, KFENCE, and MODULE_SIG are on.
• IO_URING, KEXEC, and KEXEC_FILE are =y.

Lockdown and the allowlist still constrain unallowlisted programs and (when engaged) new module loads. That is policy, not ENOSYS.

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

Do not choose it expecting the 5.19.6 compile-out brochure on a 6.18.9-hs host. BPF, FUSE, OverlayFS, user namespaces, and AppArmor are present on this pin. Local eBPF tooling and FUSE are not ENOSYS.

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

• The 5.19-style compiled-out bypass list (BPF=n, IO_URING=n, KEXEC=n, …)
• KSPP items still FAIL on this pin (INIT_ON_FREE, KSTACK_ERASE, MODULE_SIG_FORCE, …)

Root Lock is not a replacement for network firewalls, WAFs, SIEM, or EDR hunting. It is host-local kernel enforcement.

Verification

Pin config SHA-256: 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9
vmlinuz SHA-256:    1b44fffb9b570497f19f4c68e170602b542bc84bfe9f49d936c123dc59f5db8a
uname -r:           6.18.9-hs
file(1) build:      #37
Tool: https://github.com/a13xp0p0v/kernel-hardening-checker (commit e870d0141259f875d3d1b54fef49dec7074e4cac)
Expected checker:   OK 148 / FAIL 111

Do not hash guest /boot/config-6.18.9-hs (11-line RD stub). Full methodology: evidence-pack-6.18.9.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 (based on mainline LTS releases such as 5.19.6 and 6.18) so that enforcement cannot be bypassed by an attacker who already has remote root.

The design removes at build time the kernel features most commonly used as bypass vectors for security controls:

• The BPF syscall (CONFIG_BPF_SYSCALL) — there is no eBPF layer an attacker can load programs into or unload.
• User namespaces (CONFIG_USER_NS) — no unprivileged fake-root environment for container escapes or privilege escalation.
• FUSE and OverlayFS — path-confusion and mount-based bypasses against VFS-level enforcement are unavailable.
• Competing LSM frameworks (AppArmor, TOMOYO, and runtime SELinux enforcement) and related policy engines — no parallel policy that can be set permissive or edited to weaken decisions.

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. Root Lock removes the primitives that let a compromised process escape its intended boundary in the first place.

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

The result is a deliberately smaller kernel (approximately 9 loadable modules versus thousands in a general-purpose distribution) whose configuration is published with a SHA-256 hash for independent verification.

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). Updates follow the same maintenance window model as policy changes: boot the maintenance kernel, apply the bundle, return to the Root Lock kernel, and review.

  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: The Kernel Security Transparency page provides per-CVE status with technical rationale. Features compiled out produce “Not Affected” entries — the vulnerable code path is absent by design; no patch or policy change is required. For reachable code paths, Lockdown’s allowlist bounds post-exploitation impact: new programs cannot execute, mounts are refused, and changes to sealed configuration are blocked.

  Scores on HeartSuite are computed and published. 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. Expanded test coverage for UEFI Secure Boot paths is tracked alongside the existing partial e2e validation.

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).
• Container workloads with fixed pod sets established before Lockdown engages (see deployment notes in How Root Lock Compares).
• EDR and observability via log forwarding (no on-host eBPF attachment). Enforcement events flow through syslog. Denial logs cover 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.) — the BPF syscall is omitted.
• Dynamic Kubernetes environments with frequent pod creation, HPA scale-out, or rescheduling after Lockdown (mount operations required for new containers are refused).
• KVM hypervisor hosts. Root Lock runs as a guest.
• Rootless / unprivileged user-namespace containers.
• Any workload that needs a compiled-out kernel feature for its core function.

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 for one stock boot — 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. 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 the operator. 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: reboot to maintenance kernel, remove the immutable seal, make changes, reboot back to the Root Lock kernel, review new activity, and re-engage Lockdown.
• The Dashboard’s Maintenance ([m]) handles the common case of quick maintenance-kernel work followed by guided return to the Root Lock kernel and review.
• 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 console access (local keyboard/monitor, serial, or cloud provider serial console) is always sufficient to select the maintenance kernel and regain full control. No software on the system can block this path.

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 with the exact “Not Affected / Score on Root Lock 0.0 / bounded impact” rationale on the Kernel Security Transparency page.
• 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 and root-immunity. 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, compiled-out bypass primitives, 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.

This page is buyer-facing. Posture claims must match the fielded pin in Evidence Status. Last updated: 2026-08-20.

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 as of 2026-08-18. It replaces the April 2026 v1.6.4 “Validated” table (Fedora 41, Alpine 3.21 as validated, Ubuntu 22.04 omitted).

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:

Do not read “Supported” as “Lockdown certified on this date.” The latest completed M2 release-core campaign (2026-08-18) finished PARTIAL on all four core guests (Release eligible: no).

Columns

• Kernel line — Which Root Lock kernel the current installer for that row ships. New Debian 12/13 and Ubuntu 22.04/24.04 images use 6.18 (uname -r is 6.18.9-hs on the fielded pin). Debian 11 and Ubuntu 20.04 use 5.19 only. 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.

Source for rows and kernel series: heartsuite/tools/live_matrix/distro_catalog.yaml (2026-08-18).

Main compatibility table

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

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. HeartSuite runs install, first boot, and initial setup against it in the live matrix. As of 2026-08-18, Lockdown M2 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. They must never consume the current k6 / 6.18 bundle.

Compatible (customer validation)

Same packaging family as a tested row. HeartSuite has not published results for your exact vendor branding, minor, or gold image.

Rocky 9 lab coverage does not certify every Rocky 9.x or AlmaLinux 9.x minor. RHEL 8/9 require validation on the customer’s subscribed minor.

Not supported

Outside current product scope. Use a supported distribution, the maintenance kernel on a separate host for incompatible workloads, or HJFS on a standard kernel where custom kernels are prohibited.

RPM / RHEL family

Lead with Rocky 9 (in lab) for RHEL-compatible userspace. Re-run install and Lockdown on the current k6 bundle; do not treat a 2026-07 BLS path as a standing certificate.

SELinux on RHEL-family systems: On RHEL and Fedora, SELinux is Enforcing by default. 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/13 and Ubuntu 22.04/24.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

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. That is a support-scope statement. The fielded 6.18 pin compiles CONFIG_KVM=m; do not read “not supported” as “KVM is compiled out.” 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.

The two kernel lines are not the same configuration.

On the current 6.18 pin, “this tool cannot run” is not an ENOSYS / compiled-out claim for eBPF, FUSE, OverlayFS, user namespaces, AppArmor, or KVM. A program can still fail because it is not on the allowlist, because Lockdown refuses a new mount or a new module load, or because the role is unsupported.

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 #37). Absence of the word HeartSuite does not mean you are on the maintenance kernel.
   • 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 (5.19.6 measured pack)
• 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-08-18. Rows follow distro_catalog.yaml. Workload Kconfig values are from the fielded 6.18.9-hs #37 config and the published 5.19.6-HeartSuite-1.0 pack. No complete Lockdown M2 release-core gate exists 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 streams currently shipped and supported:
  • 6.18 — primary LTS stream and commercial baseline (HeartSuite v1.6.4 ships kernel 6.18.9).
  • 5.19 — legacy stream for existing deployments; no longer the default for new installations.
• 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 a legacy exception: 5.19 was a short-lived mainline release. It remains in this policy only for existing deployments until the deprecation window closes.

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 (compiled-out subsystems, 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:

HeartSuite is honest about the trade-off: the Root Lock kernel is not a drop-in substitute for a distribution kernel in every operational sense. It is 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. Packaging label is 6.18.9-HeartSuite-3 (build #37). 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 the HS-vs-maintenance test is uname -r plus file on vmlinuz, as documented in Evidence Status. The fielded pin is 6.18.9-hs.

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. The Root Lock kernel is not the distribution enforcement kernel.
• 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.

1. If Lockdown is applied, unseal from the console first. That trip is not the install boot.
2. From a terminal in Setup Mode, run bash heartsuite-install.sh and type YES. That takes one stock or maintenance boot and continues the update. The default stays Root Lock.
3. If you are already on the original distro kernel or the maintenance kernel and Lockdown is not applied, run the installer. There is no YES step.

Root Lock is not loaded on that stock or maintenance boot: 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

• Many high-severity CVEs are Not Affected on Root Lock kernels because the attack surface was never compiled in. Those entries do not consume patch-tier clocks.
• 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 commit to per-CVE errata identifiers in the distribution-vendor style. Bundle manifests list addressed CVEs for the 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 an Root Lock kernel stream (for example, end of 5.19 support). Notice includes migration bundle availability and recommended maintenance windows.

Machine-readable advisory feeds are published as JSON under /advisories/ on each annotated hs-v* release tag.

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. HeartSuite no longer recommends 5.19 for new deployments or new pre-configured images.

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, module footprint, 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 require BPF, specific kernel modules, or kernel interfaces absent from the Root Lock kernel should run on a kernel that still exposes those interfaces, or on a separate host.

The Root Lock kernel omits these by design to eliminate bypass primitives and attack surface. See the Enterprise Adoption Guide compatibility section and Reduced Kernel Footprint.

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 (for example, mainline 6.18.9 with a HeartSuite release suffix such as 6.18.9-HeartSuite-1.0).

The version string tells you the LTS line and HeartSuite bundle revision. 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-HeartSuite-1.0, 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), Score on Root Lock 0.0 (environmental neutralisation), or bounded impact under Lockdown (reachable code path with post-exploitation constraints).

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 Root Lock kernel, output ends in HeartSuite (for example, 6.18.9-HeartSuite-1.0 or 5.19.6-HeartSuite-1.0). If the string does not contain HeartSuite, you are on 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 running Root Lock kernel (configuration-level proof):

grep CONFIG_<GATE> /boot/config-$(uname -r)

Replace CONFIG_<GATE> with the gate named on the transparency page. An =n result confirms the option is not compiled in.

Example (AF_ALG / CVE-2026-31431):

$ grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
CONFIG_CRYPTO_USER_API_AEAD=n

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, config-gate grep results, and bundle SHA-256 verification output from Step 1 and Step 4.
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 transparency page applies four assessment gates in order: (1) compiled in?, (2) outbound control coverage?, (3) can an exploit program run under Lockdown?, (4) what can root do under Lockdown? See Scanner Guidance on that page for the full gate definitions. 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 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 (HeartSuite absent from uname). 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 is not the operative model for the currently running stack.
• 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.

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-HeartSuite and reports Critical/High.

HeartSuite reality: CONFIG_BPF_SYSCALL is not compiled into the Root Lock kernel. The bpf() syscall returns ENOSYS. There is no verifier, no program store, and no reachable path — status Not Affected for the entire BPF syscall interface group.

Proof:

$ grep CONFIG_BPF_SYSCALL /boot/config-$(uname -r)
# CONFIG_BPF_SYSCALL is not set

FUSE-related CVEs when CONFIG_FUSE_FS=n

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

HeartSuite reality: CONFIG_FUSE_FS is not compiled in. FUSE-based path confusion and mount bypass primitives are unavailable — status Not Affected for the FUSE filesystem group.

Proof:

$ grep CONFIG_FUSE_FS /boot/config-$(uname -r)
# CONFIG_FUSE_FS is not set

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 — grep CONFIG_* /boot/config-$(uname -r) output for compiled-out findings
• Bundle integrity — sha256sum -c heartsuite-install.sh.sha256 output (or subscription delivery record)
• Config hash match — sha256sum of /boot/config-$(uname -r) compared to published hash for that release
• 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 — without overstating availability.

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.

It does not by itself prove publisher identity. That is why GPG and cosign 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 guest /boot/config-$(uname -r) on 6.18.9-hs. 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 #37)
• 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 — detect accidental corruption or tampering in transit if you verify against the published checksum before execution.

Planned:

What HeartSuite is not claiming yet:

• No published GPG public key or cosign policy on this site today.
• No requirement that customers use signing before install — SHA-256 verification remains the baseline until signing is generally available.
• Signing addresses publisher authenticity and pipeline integration; it does not change the Root Lock kernel’s CVE reachability model or Lockdown semantics.

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 (JSON under /advisories/, absolute base https://docs.heartsecsuite.com/advisories/):

For release tag hs-v1.6.4-kernel-6.18.9 (gate_status: PASS in the catalogue):

• 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. HeartSuite remediation is expressed through coordinated bundles and transparency documentation, not per-CVE RPM errata on the HS 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). A missing HeartSuite substring still matches that pin.
   • Look up the CVE on Kernel Security Transparency.
   • Verify compiled-out claims against the pin payload config. Guest /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 Non-Root Lock kernel maintenance windows and for non-kernel packages.

OVAL XML general availability will be announced in release notes when ready.

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 #37 pack published 2026-08-18 — 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 by HeartSuite kernel evidence
Fielded 6.18 pin: 6.18.9-hs / packaging 6.18.9-HeartSuite-3 / build #37
Legacy stream: kernel 5.19.6 (maintenance-only; see Kernel Support Policy)

Summary

The two lines do not share the same kernel config. 5.19.6 compiled out BPF/FUSE/OVERLAY/USER_NS/AppArmor/TOMOYO. Fielded 6.18.9-hs #37 compiles those in. Treat 5.19.6 scores as legacy, not as a substitute for 6.18.9-hs.

What is published today (6.18.9-hs #37)

• Identity — uname 6.18.9-hs, file #37, vmlinuz SHA-256 1b44fffb…, pin config SHA-256 3cd18247… in evidence-pack-6.18.9.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: 74 modules loaded, 4190 .ko.xz, LSM lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm, Root Lock activate at t+4s
• Buyer and auditor summaries — Procurement Brief and Threat model now follow this pack

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 RD stub. CONFIG_IKCONFIG is off. Analysis uses the pin payload config whose SHA matches VERSION_MAP.
• This is the fielded pin, including IO_URING=y, KEXEC=y, KEXEC_FILE=y. It is not a derived unpublished hardening cut.

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.

Evidence parity roadmap

For procurement and audit teams

Evaluating a 6.18.9-hs deployment today

• Use evidence-pack-6.18.9.txt and Threat model.
• Confirm uname -r is 6.18.9-hs and file on vmlinuz contains #37. Absence of the word HeartSuite does not mean the maintenance kernel.
• Do not close BPF/FUSE/io_uring scanner findings as compiled-out on this pin.

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

Subject: Root Lock by HeartSuite, fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37)
uname -r: 6.18.9-hs
Config SHA-256 (pin payload): 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9
vmlinuz SHA-256: 1b44fffb9b570497f19f4c68e170602b542bc84bfe9f49d936c123dc59f5db8a
Tool: kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac, run 2026-08-18
Source file: evidence-pack-6.18.9.txt
Legacy (published): Hardening scores: 5.19.6, evidence-pack-5.19.6.txt

This page measures the fielded #37 pin. It is not a derived unpublished cut. CONFIG_IO_URING, CONFIG_KEXEC, and CONFIG_KEXEC_FILE are =y. Guest /boot/config-6.18.9-hs is an 11-line RD stub — hash the pin payload config.

Part 1 — Measured comparison

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are era-matched 6.18.x (no 6.18.9-hardened in the Arch archive).

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 (checker b9b83a0, 132 / 109 item denominators).

What this shows

HS 6.18.9-hs does not lead attack-surface (43.5% vs era-matched Arch 58.0% and vanilla 6.18.9 defconfig 67.2%). Bypass primitives that 5.19.6 compiled out are on here.

HS 6.18.9-hs does sit 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%).

Bypass-primitive options — measured

Exploit-resistance mitigations — measured

Part 2 — Qualitative orientation (cross-project)

Part 3 — LSM stack and module count (measured)

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 6.18 notes: evidence-pack-6.18.9.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

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/8 disabled. Arch lh: 3/8 disabled (different 3). 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 and module count (measured)

Part 4 — CPU mitigations (5.19.6 naming)

5.19.6 uses pre-6.1 option names. Checker reports these as FAIL (uses the 6.1+ CONFIG_MITIGATION_* names). Mitigations confirmed present:

Summary

10 - What a red team should test on this kernel

Subject: Root Lock by HeartSuite — fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37); 5.19.6 legacy
Evidence status: Measured config SHA-256, checker output, and runtime verification for 6.18.9-hs #37 are in evidence-pack-6.18.9.txt (2026-08-18). The 5.19.6 pack remains the legacy measured stream.
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

This page describes the fielded #37 pin. It does not describe a derived unpublished cut that turns IO_URING / KEXEC off. Those options are =y on the binary that boots.

Threat model

Root Lock targets a process on the protected system attempting to bypass VFS-level enforcement. On the 5.19.6 pack that was done mainly by compiling bypass primitives out. On the fielded 6.18.9-hs pin those primitives are compiled in. Enforcement on this pin is the Root Lock allowlist and Lockdown, running alongside other LSMs, not instead of a compiled-out surface.

What the measurements show (6.18.9-hs #37)

Tool: kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac, 2026-08-18, against pin config SHA-256 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9.

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are the era-matched 6.18.x peers (no 6.18.9-hardened in the Arch archive). Do not mix these percentages with the 5.19.6 pack (b9b83a0, different item universe).

Attack-surface reduction

Automated score: 57/131 (43.5%)
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%).

The fielded pin does not lead this axis. Pin greps: CONFIG_BPF_SYSCALL=y, CONFIG_IO_URING=y, CONFIG_FUSE_FS=y, CONFIG_OVERLAY_FS=m, CONFIG_USER_NS=y, CONFIG_SECURITY_APPARMOR=y, CONFIG_SECURITY_TOMOYO=y, CONFIG_KEXEC=y, CONFIG_KEXEC_FILE=y.

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 is above vanilla 6.17 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: 148/259 (57.1%).

Runtime (Debian 12 guest, 2026-08-18)

Guest hs-test-debian-12-k6-3-20260818-1705 (192.168.122.167), 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
• lsmod: 74 modules loaded; 4190 *.ko.xz under /lib/modules/6.18.9-hs; modules.builtin 198
• 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 is 78/110, not the 5.19.6 vanilla-baseline story. 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 “sole enforcing MAC / SELinux permissive / no securityfs” write-up is false 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. CONFIG_MODULE_SIG_FORCE is not set. kernel.modules_disabled=0. Lockdown’s kmod block, when engaged, is still an operator-procedure mitigation for new loads after Lockdown.

4. Can root unseal the allowlist or turn enforcement off?
Root cannot lift the allowlist seal or turn enforcement off through an intended agent kill. Seal and control integrity are kernel-enforced product contracts. Extra syscalls and sibling attributes on this pin still need live gates. Do not treat the architecture diagram as the gate list.

Confirm live gates on the deployed ship pin (6.18.9-hs #37). Checker percentages measure the published .config; they sit next to a residual-risk list for architecture review.

5. Allowlist breadth after learning
Setup Mode records observed behaviour. You ratify grants. Residual risk after Lockdown includes an allowlist wider than the intended slice.

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. An allowlisted powerful role can still be abused inside its grants.

8. Portable open flags and size mutation under a read grant
By default Root Lock does not redefine the O_RDONLY|O_TRUNC UAPI corner. A program with a read grant can still change file size if DAC write allows the truncate.

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: 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9

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

Bypass-primitive greps on the pin config:

grep -E "^(CONFIG_BPF_SYSCALL|CONFIG_IO_URING|CONFIG_FUSE_FS|CONFIG_OVERLAY_FS|CONFIG_SECURITY_APPARMOR|CONFIG_SECURITY_TOMOYO|CONFIG_KEXEC|CONFIG_KEXEC_FILE|CONFIG_USER_NS)=" \
  config-6.18.9-hs

Runtime on a guest whose file /boot/vmlinuz-$(uname -r) contains #37:

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.

11 - SELinux, AppArmor, TOMOYO — a different job

Subject: Root Lock by HeartSuite, kernel 5.19.6
Audience: Security engineers familiar with SELinux, AppArmor, or TOMOYO evaluating HeartSuite for containment or appliance deployments.

The core distinction

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?

HeartSuite answers a different question: which kernel features should exist on this system at all?

This is not a claim that one approach is universally superior.

For single-purpose containment appliances, removing bypass primitives from the kernel is more reliable than writing policy around them. Policy can be misconfigured. Certain primitives (BPF, FUSE, overlayfs) can defeat any MAC policy regardless of how carefully it is written.

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. 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.
• BPF tooling, container runtimes, FUSE mounts, and user namespaces are not part of the system’s attack surface — they are absent from the 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

HeartSuite does not stack with AppArmor or TOMOYO. Both are kernel-disabled (CONFIG_SECURITY_APPARMOR=n, CONFIG_SECURITY_TOMOYO=n).

SELinux behaves differently depending on the deployment OS:

HeartSuite’s VFS hooks fire before the LSM chain (security_path_*() calls). The ordering means:

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

This is intentional and safe. On RHEL/Fedora, SELinux is Enforcing by default; the stacking is additive, not conflicting. On Debian/Ubuntu, no SELinux policy is loaded by default. Either way, 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.

Root Lock enforcement is unaffected. SELinux operates after Root Lock in the hook chain and cannot override Root Lock decisions.

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.

Root Lock ships a Linux kernel with 9 loadable modules. A standard Debian Linux system typically ships 3,500 to 4,000.

That count is not a capability cut. The kernel is built for one job. Nothing else is included.

Root Lock also disables the kernel features most often used to bypass security controls: BPF (a programmable kernel interface), FUSE (user-space filesystems), overlay filesystems, and competing security policy engines including AppArmor and SELinux. Each of these has been used in documented real-world attacks to escape software sandboxes or override security policies.

On a run of the open-source kernel-hardening-checker config linter — the same tool Linux kernel security researchers use — the Root Lock 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.

Arch linux-hardened scores lower on this axis because it keeps BPF, FUSE, and AppArmor enabled. Its general-purpose users depend on those features. They also provide paths for bypassing security controls.

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. 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 prevent attacks from bypassing its controls. It is not designed to harden against every possible kernel vulnerability.

The configuration is publicly verifiable. The SHA-256 hash of the kernel configuration file is published. Any qualified security team can reproduce the measurements above using publicly available tools.

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