r/kernel 10d ago

Struggling with PID1 + Chain‑of‑Trust Boot Flow (Custom Runtime OS Project)

Hey folks,
I’m building a small experimental OS/runtime hybrid and I’ve hit a wall with PID1 behavior and the chain‑of‑trust during early boot. Hoping someone here has fought similar dragons.

Context

I’m not building a traditional Linux distro.
This is a governed runtime with its own mediation layer, identity checks, and a compatibility membrane for foreign binaries. PID1 is extremely minimal — it’s basically:

  • initialize the invariant engine
  • mount the pattern ledger
  • bring up the mediation layer
  • hand off to the user‑level runtime

No systemd, no BusyBox init, nothing fancy.

The Problem

When the system boots, the firmware verifies the shim → kernel → initrd just fine.
But once my custom PID1 takes over, the chain‑of‑trust becomes fragile:

  1. PID1 sometimes fails to verify its own signature Even though the binary is signed and measured correctly, the verification step occasionally returns “unreadable” or “missing measurement.”
  2. Ledger mount timing issues The pattern ledger (think: structured state log) sometimes mounts after PID1 tries to validate it, causing a soft‑fail that cascades.
  3. PID1 is too fragile Any hiccup in the trust chain causes PID1 to panic instead of gracefully retrying or falling back.
  4. Firmware vs runtime identity mismatch The firmware expects a static identity, but the runtime uses a dynamic identity model (based on behavior + signature). They don’t always agree.

What I’ve Tried

  • Delaying ledger mount
  • Moving signature verification earlier
  • Moving signature verification later
  • Rebuilding PID1 to be even smaller
  • Re‑signing the entire boot chain
  • Re‑measuring the initrd
  • Rebuilding the shim
  • Re‑generating the root key

Still getting intermittent failures.

What I’m Looking For

Anyone who has experience with:

  • custom PID1 implementations
  • minimal init systems
  • secure boot chains
  • measured boot
  • TPM‑based identity checks
  • early‑boot race conditions

I’m not trying to reinvent Linux — this is a research OS with a very different runtime model. I just need PID1 to stop collapsing the entire trust chain every time one measurement is late or unreadable.

Any advice, patterns, or “don’t do this, do that instead” would be hugely appreciated.

5 Upvotes

1 comment sorted by

View all comments

1

u/penguin359 5d ago

Normally, I wouldn't measure PID1 itself. I would measure the initrd and then would be able to trust any executables on it. When you transition between initramfs and the physical root disk, if you really need to execute trusted binaries only, maybe you need the root partition protected with dm-verity so that only valid blocks are read from it. This would make it more like a Linux distro such as Silverblue or rpm-ostree where the core OS is frozen and mutable data is on a different partition similar to Android.