eBootloader secure boot: a measured-launch walkthrough

Chain of trust

eBootloader's chain of trust starts before any code runs. The root-of-trust public key is fused into one-time-programmable (OTP) memory at provisioning. Stage 0 — a 4 KB immutable bootrom — verifies the next stage's signature against that key before transferring control.

Stage progression

Stage 0 (4 KB, OTP): verifies stage 1 signature. Anti-rollback counter is incremented in OTP.
Stage 1 (32 KB, signed): verifies signed manifest, sets up MMU, loads stage 2 from primary or fallback partition.
Stage 2 (eOS RTOS image, signed manifest): verifies all loaded modules against the manifest before scheduling user code.
Runtime attestation: EAI calls eboot_attest() at model load to assert the live image hash matches what was booted.

Anti-rollback counters

Each signed manifest carries a monotonic counter. The OTP-backed comparator refuses to load any image with a counter lower than the high-water mark. This is the only defense against a signed-but-vulnerable older image being re-flashed by an attacker who controls the storage bus.

// eBoot anti-rollback (stage 0 pseudocode)
hwm = otp_read_u32(OTP_HWM_OFFSET);
if (manifest.counter < hwm) {
    panic("anti-rollback violation");
}
if (manifest.counter > hwm) {
    otp_write_u32(OTP_HWM_OFFSET, manifest.counter);
}

Runtime attestation

Once stage 2 is running, downstream subsystems can request a measurement of the boot chain via eboot_attest(). The returned blob is signed by a key derived from the device root, suitable for forwarding to a remote verifier. EAI uses this before unsealing model weights — we describe the integration in our EAI release post.

Non-goals

eBoot is not a TEE. There is no parallel secure-world execution context. If your threat model includes a kernel-level adversary running concurrently with secure code, you want EoS-S, not eBoot.

Filed under:Security & Boot