Kernel vs Userland — why boot order matters.
There are two ways to add capabilities to a Linux system: load them into the kernel, or run them as a process in userspace. Both work. But they have fundamentally different security properties, and the difference comes down to when they start.
The question isn't "does this feature exist on the system?"
The question is: "At what point during boot is this feature protecting me?"
What boots when
Two models
Push Mode / Userland Daemon
A process starts, reads configuration, and pushes eBPF programs or firewall rules into the kernel. Examples: Cilium, Calico, Falco, Datadog agent.
Native / Kernel Module (DKMS)
A module loads with the kernel itself. It's in memory before any process exists. Examples: WireGuard, ZFS, NVIDIA drivers, eBPF subsystem.
The trade-offs
| Userland (push) | Kernel (native) | |
|---|---|---|
| Available at | 3–15 seconds after boot | Instant — loads with the kernel |
| Vulnerability window | Yes — unprotected until daemon starts | None — active from second zero |
| Can be killed | Yes — crash, OOM, misconfiguration | No — cannot be killed from userspace |
| Update method | Reload config, restart daemon. No reboot. | DKMS rebuild on kernel upgrade. May need reboot. |
| Hot reload | Yes — change policy in seconds | Limited — module parameters, not full reconfiguration |
| Attack surface | Daemon process, config files, API endpoints | Kernel memory only — no API, no config parsing at runtime |
| Trusted boot chain | Not part of it — loads after boot completes | Signed via MOK — tamper-evident from firmware |
| Maintenance | Simple — package update, restart | DKMS rebuild on kernel upgrades across distros |
| Flexibility | High — dynamic policy, runtime changes | Low — behaviour defined at load time |
How kldloadOS layers them
This isn't a choice between one model or the other. They're complementary. The kernel layer closes the vulnerability window. The userland layer provides flexibility on top. kldloadOS ships both — pre-assembled, in the right order.
Layer 1 — Kernel (second zero)
WireGuard — network encryption active before any process starts. ZFS — checksummed, encrypted filesystem from first mount. eBPF subsystem — the tracing infrastructure is live in kernel memory. NVIDIA — GPU available without waiting for a runtime.
Layer 2 — Userland (seconds later)
eBPF tools — execsnoop, tcplife, biolatency attach to the kernel subsystem. Cilium — loads network policies via eBPF (on K8s workloads). Ollama — AI inference daemon. Sanoid — automated ZFS snapshot scheduling.
Why this matters
Most platforms ship userland tools and call it security. The daemon starts, loads its rules, and then you're protected. But what about the seconds before that? What about when the daemon crashes at 3am?
kldloadOS closes the window at the kernel level. WireGuard encrypts the network before systemd starts. ZFS checksums every block before any process reads it. The eBPF subsystem is tracing before any observability daemon initializes.
By the time Cilium loads its first policy, kldloadOS has been protecting the system for 10 seconds.
That's not a minor architectural detail. That's the difference between a system that is secure by default and one that becomes secure eventually.