Boot Flow

Purpose

Boot is a central piece of the Bunker-Centric Architecture (BCA). For production devices, secure boot must be enabled to establish the chain of trust from immutable hardware roots to running services. This section gives a high-level overview; platform-specific details, recipes and provisioning steps are documented in each platform guide.

Design Principles

  • Secure boot by default: production images must enable vendor secure boot mechanisms and verify every stage before execution.

  • Vendor alignment: BCA embraces vendor boot primitives (SPL/FSBL, vendor containers). We integrate with vendor tooling rather than replace it.

  • Minimal trusted computing base: signed binaries, measured boot and hardware-backed keys (fuses/RPMB) form the root of trust.

Reference Flow

The reference design typically follows this pattern (vendor-dependent formats and names apply):

  1. SPL / First-stage loader loads a single signed payload image (the “bundle”).

  2. The bundle contains verified components: firmware, TEE (OP-TEE), hypervisor, and vendor bootloaders/U-Boot instances. - The reference layout includes two U-Boot images: a full U-Boot for the Open World and a minimal, hardened U-Boot for the Bunker OS.

  3. Each element is integrity-checked (signature verification) before execution; signatures are validated against public keys provisioned into device fuses.

  4. The hypervisor is started and creates VM contexts for Bunker OS and Open World; the hypervisor then boots the respective kernels.

Notes on vendor formats and variability

  • Different vendors provide different packaging tools and formats. See the platform guide for the exact commands and manifest formats.

  • BCA is centered around platform vendors supports to “enable” their secure boot features and to adapt BCA reference packaging to the platform’s constraints.

Kernel integrity, lockdown and modules

  • The Linux kernel used in Bunker OS is measured and validated during the boot sequence (u-boot or vendor firmware performs kernel signature checks).

  • Kernel lockdown and module signing are enforced: loadable kernel modules used by Bunker must be signed with trusted keys, and distribution of module signing keys and provisioning steps are described in the platform documentation.

  • Development note: enabling module signing and lockdown impacts development workflows; follow the platform guide for testing and key provisioning practices.

Provisioning and keys

  • Public verification keys are expected to be provisioned into hardware one-time storage (efuse, RPMB) under customer control — Accelerat does not hold customer private keys.

  • Platform guides contain recipes to configure meta-layers, sign images, and provision keys for each supported SoC.

Boot partition and access model

  • The boot partition contains the signed bundle and kernel artifacts. In reference deployments it is only accessible to the Bunker OS and the secure boot process; Open World should not be able to modify these artifacts.

  • If an image is tampered with, verification fails and the platform will not proceed to boot (fail-secure behaviour).

Hypervisor behavior

  • The hypervisor launches both Linux domains (Bunker OS and Open World) following verified images and policies.

  • Device assignment and virtualization policies are enforced by the hypervisor; these are configured per-platform with the hypervisor configuration and accordingly in the respective Yocto/meta layers.

Customizations & encrypted binaries

  • If your deployment requires encrypted FPGA bitstreams, vendor IP, or bespoke payload encryption, this is supported but requires platform-specific configuration and support engagement.

  • Contact our support team for engineering and validation assistance for encrypted bitstreams or non-standard boot customizations: support@accelerat.eu

Where to go next

  • Platform secure-boot and provisioning: see the platform guide for your SoC.

  • Implementation details for BCA images and recipes: see Meta Layers Reference.