A custom kernel in a regulated fleet

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

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

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

Why a custom kernel

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

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

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

Root Lock does not rely on an unloadable eBPF policy.

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

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

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

What Root Lock owns for kernel risk

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

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

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

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

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

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

Deployment mitigations: hiding kernel details in practice

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

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

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

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

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

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

Secure Boot, firmware compatibility, and roadmap

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

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

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

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

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

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

Compatibility and certification

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

Works with (standard configurations):

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

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

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

Decision tree (high level)

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

Operational model for fleets

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

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

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

Commercial subscription and kernel support

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

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

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

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

Supply chain transparency and integrity

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

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

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

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

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

Recovery and fallback: the maintenance kernel as supported escape hatch

Every installation retains a first-class recovery path:

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

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

Evidence and independent verification for customers and auditors

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

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

Honest limitations

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

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

In those cases the supported path is:

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

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

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

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

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

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

Next steps for enterprise evaluation

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

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

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