System Components

This document describes the components that make up Bunker-Centric Architecture (BCA) and how they map to the reference design. The BCA architecture is component-agnostic: it defines logical roles that must be fulfilled. The reference design provides concrete upstream implementations for each role.

BCA Components and Reference Design

BCA defines six logical runtime components. Additionally, the reference design provides the Bunker Development Framework (BDF) as a build-time component for creating images and customizing deployments. The table below shows each component’s logical role, reference implementation, purpose, and trust level:

BCA Component

Logical Role

Reference Implementation

Purpose

Trust Level

Open World

General-purpose domain (one or more OSes, any vendor)

Yocto-based Vanilla Linux image

Customer workloads, network services, untrusted applications

Untrusted

Hypervisor

Type-1 hypervisor managing isolation between domains

CLARE-Hypervisor

Domain lifecycle, memory isolation, hardware arbitration, inter-VM communication

Trusted

Bunker OS

Trusted domain for security-critical services

Yocto-based hardened minimal Linux

OTA updates, logging, key management, storage control, monitoring

Trusted

Bunker TEE

Trusted Execution Environment in ARM TrustZone secure world

OP-TEE

Cryptographic operations, secure key storage, boot verification, attestation

Trusted

Bunker FW

Firmware services; part of root of trust

TF-A (Trusted Firmware-A)

Secure world init, boot chain relay, platform security config, SMC routing

Trusted

Bunker RTOS

Real-time subsystem, physically isolated from the Cortex-A complex

FreeRTOS

Deterministic real-time control, independent safety monitoring, trusted I/O ownership

Trusted (platform-dependent)

Bunker Development Framework (BDF)

Build system and development tools

Yocto-based collection of meta-layers, recipes, and utilities

Building images, key provisioning, customization, platform bringup

Not applicable (build-time)

See Introduction for background on the BCA architecture model.

Open World

Open World is the domain that runs general-purpose workloads, customer applications, and network-facing services. BCA does not mandate a specific OS: Open World can host one or more operating systems, including proprietary ones, as long as the hypervisor can enforce isolation. In the reference design, Open World is a Yocto-based general-purpose Linux image. It is the domain that interacts with the outside world: it has direct network connectivity and exposes user-facing services.

Trust level: The architecture assumes Open World may be compromised at any time. Security-critical operations are fully segregated in Bunker OS and Bunker TEE and not directly reachable except through explicitly exposed, policy-controlled interfaces, regardless of the level of compromise. See Security Model for the threat model and containment guarantees.

Characteristics:

  • Runs as a virtual machine managed and isolated by CLARE-Hypervisor

  • Has direct network connectivity (Ethernet, Wi-Fi, or other interfaces as assigned by the hypervisor)

  • No direct access to Bunker OS storage or memory (all access mediated by the hypervisor or Bunker OS virtio backend)

  • Open World kernel and bootloader are signed and verified at boot; the rootfs is not integrity-enforced by default - integrity and/or confidentiality can optionally be applied, with secrets managed through OP-TEE or Bunker OS (see Security Hardening)

  • Fully customizable: customers add applications, services, and configuration via the Bunker Development Framework (BDF)

Inter-domain communication:

Open World communicates with Bunker OS exclusively over vsock (virtual socket over virtio), using Turmux RPC as the higher-level protocol for service calls. Files can be exchanged with integrity guarantees via AuthFS. Direct memory access, hardware register access, and kernel-to-kernel calls are not permitted.

See Networking for detailed communication patterns, and Communication Layer (vsock) and Reference RPC Implementation: Turmux for API references.

Hypervisor

CLARE-Hypervisor is the Type-1 hypervisor at the center of BCA. It starts before any Linux domain and enforces isolation for the entire lifetime of the system.

Trust level: CLARE-Hypervisor is signed and verified at boot as part of the binary payload loaded by the SPL or ROM bootloader. It cannot be modified at runtime. Its code surface is minimized by design to reduce the attack surface. CLARE-Hypervisor is engineered for safety and security in critical environments and has been deployed on thousands of safety-critical systems worldwide with proven track record and industry certifications.

Responsibilities:

  1. Domain lifecycle management: Creates and manages the Bunker OS VM and the Open World VM. Handles resource allocation, CPU scheduling, and domain restart policies.

  2. Memory isolation: Enforces memory isolation through multiple hardware mechanisms, including Stage-2 MMU page tables (for virtual-to-physical translation), system-level MMU (where available), and other platform-specific security features. These layers work together to ensure intended to prevent unauthorized cross-VM access, assuming correct hypervisor/platform configuration.

  3. Hardware arbitration: Owns and assigns physical devices to domains. All security-critical devices (cryptographic engines, tamper monitors, secure storage) are assigned to Bunker OS. Open World receives the devices it needs to function, which may be virtualized (virtio-blk, virtio-net, etc.) or direct passthrough depending on deployment configuration. The assignment policy is customizable per deployment.

  4. Inter-VM communication: Implements the vsock transport (virtio-based) used by Turmux RPC and AuthFS for structured inter-domain communication.

  5. Exception handling: Routes hardware exceptions and interrupts to the appropriate domain. Mediate Secure Monitor Calls (SMC) to TF-A and OP-TEE.

Configuration: CLARE-Hypervisor configuration is platform-specific and is provided through XML-based configuration files. These configuration files are generated using CLARE-Toolkit, which is available under agreement within the CLARE-Hypervisor project. Configuration includes CPU and memory assignment for each VM, device passthrough rules, and security policies.

Contact Accelerat for access to CLARE-Toolkit and platform-specific configuration guidance.

Bunker OS

Bunker OS is a minimal, hardened Linux image that acts as the trusted domain. It is started by the hypervisor and provides security and system services for the entire system. In the single-storage configuration, Bunker OS must be booted first to act as the storage backend for Open World (see Storage Models). In dual-storage configurations, both domains can be started concurrently.

Trust level: Bunker OS runs as a trusted VM/domain with assigned resources and privileged service responsibilities. Its kernel runs with lockdown enforced and all loaded kernel modules must be signed; unsigned modules are rejected at load time.

Network model: Bunker OS does not have direct internet access. This is a deliberate security boundary - isolating Bunker OS from the network is a core part of the security model. When Bunker OS needs external artifacts (such as update bundles), Open World downloads them and transfers them to Bunker OS via AuthFS with integrity protection. See Networking for details.

Core services:

  1. OTA Update Manager (RAUC)

    Manages update bundles. RAUC is pre-integrated with U-Boot in the reference design and provides atomic, signed updates with rollback capability. Bunker OS controls update activation; Open World cannot apply updates to boot-critical partitions independently. See Update Management.

  2. Secure Log Server

    Receives log streams from Open World via Turmux RPC and stores them in tamper-resistant format in Bunker OS secure storage. Open World cannot modify or suppress log records once they have been received by Bunker OS.

  3. Security Monitoring (Falco)

    Runs Falco to collect and analyze Open World kernel events (syscalls, process events, network activity, file access). Monitoring data is written to Bunker OS secure storage and is protected from Open World interference. See Falco Runtime Security Monitoring.

  4. Backup and Restore

    Manages encrypted backups of critical state. Backup initiation and scheduling are controlled by Bunker OS; Open World cannot initiate a backup unilaterally.

  5. Key and Certificate Management

    Manages PKI certificate lifecycle and interfaces with OP-TEE for secure key storage. All cryptographic material is customer-controlled via the Bunker Development Framework.

  6. Storage Controller (virtio-blk)

    In single-storage configurations, Bunker OS acts as the virtio-blk backend for Open World, providing a virtual block device. In dual-storage configurations, Open World has its own dedicated physical storage with direct access. See Storage Models.

Yocto integration: The Bunker OS image is defined in the meta-bunker meta-layers collection. See Meta Layers Reference for customization options.

Bunker TEE (OP-TEE)

The Bunker TEE provides a hardware-backed Trusted Execution Environment using ARM TrustZone. In the reference design this role is filled by OP-TEE (Open Portable Trusted Execution Environment), an open-source TEE maintained by Linaro and TrustedFirmware.org.

Trust level: OP-TEE runs in ARM secure world (Secure EL1). Normal world cannot directly read secure-world memory; access is via TEE client/driver/SMC-mediated APIs. Neither Open World nor Bunker OS can read OP-TEE memory or bypass its APIs.

Core services:

  1. Cryptographic operations: AES, RSA, ECDSA, SHA-2, HMAC - all with hardware acceleration where the SoC supports it.

  2. Secure key storage: Private keys and secrets are stored in OP-TEE secure storage. Where available, keys are derived from or wrapped with a Hardware Unique Key (HUK), making them physically bound to the device and non-extractable.

  3. Signature verification: Verifies digital signatures of update bundles and kernel images (e.g. as part of the RAUC update flow).

Hardware backends (platform-dependent):

  • Hardware crypto engines: AES, SHA, RSA, ECC accelerators

  • PUF (Physically Unclonable Function): hardware-rooted entropy for device-unique key derivation

  • HSM (Hardware Security Module): dedicated cryptographic processor on select platforms

  • RPMB (Replay Protected Memory Block): tamper-resistant persistent storage on eMMC

OP-TEE exposes its services through the GlobalPlatform TEE Client API (OP-TEE client API). Bunker OS services call into OP-TEE via this API; raw key material never leaves secure world.

See Security Hardening for OP-TEE configuration and Trusted Application development.

Yocto integration: OP-TEE is integrated through meta-arm and vendor BSP layers. Platform-specific configuration (OPTEE_PLATFORM, board settings) is provided in each SoC’s meta-layer. See Meta Layers Reference.

Bunker FW (TF-A)

Bunker FW provides the lowest-level firmware services: secure world initialization, platform security configuration, and part of the boot chain anchor between hardware and operating system layers. In the reference design this role is filled by TF-A (Trusted Firmware-A), the reference implementation of the ARM Trusted Boot Base Requirements.

Trust level: TF-A is verified by the SoC ROM or SPL and executes before any OS. Its signature is checked against keys provisioned in hardware fuses.

Responsibilities:

  • BL31 (EL3 runtime firmware): Handles Secure Monitor Calls (SMC), manages transitions between secure and normal world, and provides PSCI (Power State Coordination Interface) services for CPU hotplug and power management.

  • BL32 (Secure payload): Loads and starts OP-TEE as the secure payload in TrustZone.

  • Boot chain relay: Receives control from the SPL, configures the secure world (TrustZone memory regions, TZASC), and hands control to the hypervisor.

  • Platform security configuration: Sets up TZASC (TrustZone Address Space Controller), security peripherals, and memory firewall registers.

The exact integration and packaging of TF-A varies by SoC vendor. See Boot Flow and the platform-specific guides for details on how TF-A is signed and packaged.

Yocto integration: TF-A is integrated through meta-arm and vendor BSP layers. See Meta Layers Reference and the relevant platform guide.

Bunker RTOS (FreeRTOS)

Bunker RTOS provides real-time, safety-oriented services on platforms that include a dedicated Cortex-M/Cortex-R real-time subsystem alongside the main Cortex-A application processors. In the reference design this role is filled by FreeRTOS, running independently of the hypervisor and the Cortex-A domains.

Trust level: Bunker RTOS executes on a physically separate core (or core cluster) from the Cortex-A complex that hosts the hypervisor, Bunker OS, and Open World. This physical separation means Bunker RTOS availability and correctness do not depend on the state of the hypervisor or the Linux domains: it can continue operating even if the Cortex-A complex is compromised, hung, or reset.

Responsibilities:

  1. Deterministic real-time control: Runs hard real-time control loops (motor control, sensor fusion, actuator drive, industrial fieldbus protocols such as CAN/CAN-FD) with latency and jitter bounds that cannot be guaranteed by a Linux/hypervisor stack.

  2. Independent safety monitoring: Acts as a watchdog over the Cortex-A complex (hypervisor, Bunker OS, Open World), able to detect a hang or crash and drive the system to a safe state, trigger a reset, or invoke a fail-safe shutdown path.

  3. Trusted I/O ownership: Retains exclusive control of specific GPIOs, ADC/PWM channels, or sensors/actuators that must never be directly reachable from Open World, providing a physical isolation boundary in addition to the hypervisor’s logical isolation.

  4. Early boot / power sequencing: On many SoCs, the Cortex-M/R subsystem boots before the Cortex-A cores and can gate power/clock sequencing, handing off to Bunker FW and the hypervisor once the platform is ready.

  5. Trusted time source: Can provide precise, tamper-resistant timestamping for Bunker OS’s log server, independent of the Cortex-A cores’ clocks.

Communication with Bunker OS / Open World: Bunker RTOS typically communicates with Bunker OS and/or Open World through a dedicated inter-processor communication (IPC) mechanism (e.g. shared memory with a mailbox or RPMsg), separate from the vsock/Turmux RPC channel used between Cortex-A domains. The exact transport is platform-specific.

Platform dependency: Bunker RTOS applies only to platforms that expose a dedicated real-time subsystem (e.g. Cortex-M4/M7 or Cortex-R cores) alongside the Cortex-A application cores. Not all supported SoCs include this subsystem; availability is documented per platform in Porting to New Platforms and the relevant platform guide.

Yocto integration: FreeRTOS firmware images for the real-time subsystem are built and provisioned through platform-specific meta-layers, separate from the Cortex-A Yocto builds. See Meta Layers Reference for details.

Hardware Root of Trust

The hardware layer provides the immutable foundation for the entire trust chain.

Boot ROM and First-Stage Bootloader

The first executable stage and secure-boot flow are SoC-specific.

  • ROM-authenticated boot: On many SoCs, immutable Boot ROM code executes first after reset. In secure-boot configurations, the Boot ROM authenticates the first mutable boot image using keys, key hashes, or certificates provisioned into OTP/eFuses or platform-specific secure storage. If authentication fails, the boot process stops or enters a vendor-defined recovery/fail-secure state.

  • First-stage bootloader / SPL / FSBL: The first mutable boot stage may be called SPL, FSBL, or a vendor-specific boot container component. It is normally authenticated before execution and is responsible for loading and, where configured, authenticating later boot components such as TF-A, OP-TEE, the hypervisor, device trees, and OS images.

  • Vendor-specific packaging: AMD Zynq UltraScale+ uses BootROM/CSU-managed boot with FSBL and boot-image packaging; NXP i.MX8/i.MX9 families use HAB or AHAB-style authenticated boot flows where ROM authenticates the first boot image/container and subsequent stages extend the chain of trust.

Exact behavior, key material format, revocation model, and failure mode are platform-specific and documented in the relevant platform guide.

OTP Fuses, Device Secrets, and Secure Storage

  • OTP/eFuses: one-time-programmable storage typically used to hold secure-boot enablement bits, lifecycle state, revocation data, and public-key hashes or key digests used by the Boot ROM or secure boot controller.

  • Device-unique secrets: SoC-specific mechanisms such as HUK, PUF-derived keys, or HSM-held keys may be used to derive or wrap device-bound secrets. Availability depends on the SoC and provisioning flow.

  • Authenticated persistent secure storage: RPMB, where available, provides replay-protected authenticated storage for secure data, counters, or OP-TEE secure storage backends.

Customer-controlled provisioning material is injected through the platform-specific secure-boot and BDF provisioning flow.

ARM TrustZone

Hardware architectural feature enforcing the separation between normal world (Bunker OS, Open World) and secure world (OP-TEE / TF-A). Access to secure memory, secure peripherals, and hardware crypto engines is denied to normal world by hardware — it cannot be bypassed in software.

Hardware Crypto Engines (SoC-dependent)

AES, SHA, RSA, and ECC hardware accelerators. OP-TEE may use hardware crypto backends where available, offloading computation from software and reducing side-channel exposure.

Supported SoC Families (reference design):

For platform-specific hardware security features (tamper monitors, PUF availability, HSM integration), refer to the SoC-specific documentation and the relevant platform guide.

Where to Go Next