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.