[patrislav]

Inside the enclave two processes do one job. AWS's init.c mounts the filesystems, answers the parent's heartbeat and switches root, then hands off to our Go pid1, which spawns and supervises the customer's programs. That split means two languages, two build stages and two sets of behaviour to reason about for something that is a few hundred lines of work in total. This replaces both with one program.

Second of three stacked pull requests; merge the builder first. chronyd is still spawned as the first supervised child here, and the next pull request removes it.

What lands

• A new eiffel-init crate, built static for musl, that runs the whole boot sequence: block every signal, mount devtmpfs and take the console, answer the heartbeat the parent waits on, read and unlink the config files, switch root, mount the filesystem set, spawn the programs and supervise them.
• The heartbeat retries for about five seconds while the vsock transport finishes probing, and treats anything else as fatal. It runs before any slow work, because nitro-cli blocks on it and will report the enclave as failed without it.
• Supervision is a single reaping loop that owns every child. On the first direct child exit, whatever the status, the init signals everything to terminate, waits up to two seconds so apps can flush, then reboots.
• Unsafe code lives in one small module holding a single pre-exec closure that unblocks signals and starts a new session in the child. The rest of the crate denies it, and that denial was checked by deliberately breaking it.
• Every failure writes a one-line reason to the console before acting on it. In an enclave the console is the only debugging channel there is.
• The Go supervisor directory is deleted, along with the Dockerfile stage that built AWS's init. The build asserts the new binary needs no dynamic loader.

Migration for customers

The cmd file no longer accepts a /sbin/pid1 line, and that path no longer exists in the rootfs. List only your own programs. A stale cmd is rejected at first boot with a console message naming the problem rather than failing obscurely. The README carries the note.

Behavioural differences from today

• Child output is inherited rather than piped, so ordering between processes is now whatever reaches the console, not what the Go copy goroutines produced.
• A single cgroup v2 mount replaces the per-controller v1 loop. Nothing in the enclave uses cgroups, and v2 is what a current userspace expects.
• Shutdown signals children and waits briefly instead of rebooting immediately.

Verification

• Formatting, clippy with warnings denied, and the full workspace suite pass: nine builder tests and nine init tests.
• The binary builds static for musl and carries no interpreter segment.
• Two cache-free builds of the init stage produce an identical binary hash.
• No host paths leak into the binary.
• The mount sequence is expressed as a data table and asserted entry by entry, including that every mount is nosuid and noexec, that only devpts allows device nodes, and that no v1 cgroup mount exists.

Not verified

Nothing was booted. There is no Nitro hardware, and the machine this was built on cannot run the QEMU machine type that emulates one, so the boot test, the device assertions and the heartbeat plumbing are unrun. No PCR values were computed or compared.

The QEMU harness was reworked here. The arrangement tried first does not match what vhost-device-vsock actually offers, since its socket backend cannot answer a connection the guest initiates. The harness now follows QEMU's own documented setup. That change is reasoned from the upstream documentation, not from a run.

Reading PCRs back from inside the guest was left out rather than guessed at. It needs an attestation client and a request encoding that would have been recalled rather than read.

Impact

PCR0, PCR1 and PCR2 all move again. Re-pin from the PCR output.

🤖 Generated with Claude Code