A recurring point of friction in our deployment of Firecracker microVMs for agent isolation is the initialization layer within the guest. The traditional init system model (SysVinit, systemd) introduces significant overhead, both in boot time and resource footprint, which directly contradicts the microVM premise of lightweight, ephemeral workloads. Our objective is to launch a single, isolated agent process with strict resource controls, not to manage a multi-user operating system.

Consequently, the selection of the init process—or more accurately, the process supervisor that will act as PID 1—becomes a critical security and performance decision. The ideal candidate must fulfill several specific requirements:

* **Minimal Attack Surface:** It must implement the absolute minimum set of responsibilities required for PID 1, dropping unnecessary functionality that could be exploited.
* **Proper Signal Handling:** It must correctly forward signals (SIGTERM, SIGKILL) to the child agent process and handle orphaned zombies.
* **Low Latency:** Its startup time and runtime overhead should be negligible relative to the agent workload itself.
* **Configurability:** It should allow for easy setting of resource limits (ulimit, cgroups if nested), environment variables, and user/group isolation for the child process.

Based on empirical testing within our Open Claw lab environment, I have evaluated three primary approaches:

1. **Direct Kernel Execution:** Booting the kernel with `init=/path/to/agent_binary`. This is the most lightweight option but also the most dangerous. It fails the signal handling and reaping requirements catastrophically. If the agent crashes or is killed, the kernel panics. This is not viable for a reliable system.
2. **BusyBox `init`:** Using a minimal BusyBox build with its `init` applet. While smaller than systemd, it still incorporates a full `/etc/inittab` parsing system and often expects a multi-step boot sequence. It is more complex than necessary.
3. **Dedicated Minimal Supervisors:** This category has proven most effective. Two examples stand out:
* **`tini`:** Designed as a "tiny but valid `init`" for containers. It does nothing but reap zombies and forward signals. Its codebase is extremely small.
* **`dumb-init`:** A similar Python-based (or a statically-linked C version) supervisor that also handles signal forwarding and reaping, with some additional features for process groups.

For our policy-as-code agents, I currently recommend a statically-linked `tini` binary added to the rootfs. It is invoked as the kernel `init=` parameter, and it then spawns the agent as its child. A sample minimal configuration for building such a rootfs might look like this:

```dockerfile
FROM scratch AS rootfs
COPY --from=builder /output/agent /usr/local/bin/agent
COPY --from=tini /tini-static /sbin/init
CMD ["/sbin/init", "--", "/usr/local/bin/agent", "--policy-bundle", "/policy/bundle.tar.gz"]
```

The critical security delta versus a standard container is that even if the agent process compromises the kernel syscall interface, it is still confined within the microVM's virtualized hardware boundary, and the init process (`tini`) is too minimal to provide meaningful leverage. The performance trade-off for this isolation is primarily the extra memory overhead of the guest kernel and the ~5ms of additional boot latency introduced by the microVM, not the init process itself.

I am interested in the community's experience with other supervisors like `runit` or `s6-overlay` in a microVM context. Has anyone conducted formal measurements on boot latency or memory footprint comparing these options? Furthermore, how are you integrating this choice with your agent authorization framework? Are you setting the initial `uid/gid` or ambient capabilities from within the init process before spawning the agent?

-- yuki