Locked at power-on: why terminal?

[chrysh]

If the eRoT comes up unprovisioned or fails its own self-check, you latch Locked forever. But a failed self-check is what the ROM fallback path is for, and an unprovisioned device needs to get provisioned — neither of those is a dead end. Why terminal?

cc @FerralCoder @rusty1968

[FerralCoder]

We need to design our provisioning flow

[rusty1968]

The Orchestrator state machine is not the thing that fixes a broken or blank RoT. It's just the piece that runs after the RoT is already up and healthy, to boot and watch the rest of the platform. So when it's handed one of those two bad results, the right move isn't to fix it — it's to step aside and let the proper layer handle it. Here's why for each:

Self-check failed. You're right that a bad firmware image should fall back to the ROM recovery copy. But that ROM step happens before this code even starts. If this code is running and still hears "self-check failed," the only honest reading is "the firmware I'm made of can't be trusted." And a piece of code can't fix itself — the code that would run the repair is the exact code that's suspect. So it stops and hands control back down to the ROM, which restarts and does its fallback. The way out is a reboot, not a move inside this machine.

So the division of labor is:

• State Machine : decide "I can't safely supervise" and refuse, safely (Locked).
• Driver: intervene — provision, reset, or escalate.

That keeps the SM and trust-focused (it never tries to fix its own foundation), and puts the actual remediation in the driver, which is where the hardware/mode-specific machinery lives anyway. It's the same split as everywhere else in this design: the SMnames what the situation is; the platform driver decides how to act on it.

You need to internalize what the Orchestrator SM is and what is not.

What is

It is a decision engine — the eRoT's supervisor brain, and nothing else:

• It decides, it never acts. It takes in facts (Events) and produces a list of things it wants done (Effects). It touches no hardware itself.
• It runs after the eRoT is already up and trusted. Its job is to supervise the rest of the platform's boot chain — not to boot or repair the root of trust.
• It only knows what it's told. It never checks the world directly — the platform driver feeds it every fact as an event, and it decides based purely on those.

What it is not:

It is not the platform driver. The driver is the layer that carries out effects, arms watchdogs, talks to hardware, and — crucially — is the one that intervenes when the SM says "I can't safely continue."

It is not a repair mechanism for itself. It cannot re-provision itself or fix its own failed self-check; that's the ROM / provisioning flow's job, below it.

Once that's fixed in your head, the terminal states stop looking like dead-ends and start looking like hand-offs:

Unprovisioned / SelfVerificationFailed → Locked isn't "give up," it's "the SM has no safe move left; the platform driver is supposed to intervene" (provision, ROM-fallback, or reset).
The SM staying inert there is a feature: a supervisor that tried to repair its own foundation would be unsound.