System Overview¶

Key Components¶

This section provides an overview of all components that make up Bunker-Centric Architecture (BCA), as implemented by Accelerat’s reference design for ARMv8-A (aarch64) processor architectures. Each logical BCA component is paired with the concrete upstream project or product selected for the reference implementation.

BCA Component

Reference Implementation

Purpose

Security Role

Type-1 Hypervisor

CLARE-Hypervisor

Type-1 secure hypervisor managing isolation between domains

High-integrity critical asset isolation

Bunker OS

Hardened minimal Linux

Security-sensitive operations: logging, backups, OTA updates, key management

Linux-based Trusted Execution Environment

Open World

Vanilla Linux image

General-purpose workloads and customer applications

Zero-trust execution environment (strongly isolated by hypervisor)

Bunker-TEE

OP-TEE

Trusted Execution Environment leveraging ARM TrustZone

Hardware-backed cryptographic operations and passive security services

Bunker FW

TF-A (Trusted Firmware-A)

Secure boot, firmware services, secure world entry

Root of trust and secure initialization

Bunker RTOS

FreeRTOS

Deterministic real-time control and independent safety monitoring

Isolated fail-safe watchdog over the AP domain

Communication Between Environments¶

Inter-environment communication is fundamental to Bunker-Centric Architecture. The trusted Bunker domain and the Open World one must seamlessly exchange data, execute remote procedures, and share resources while maintaining strict security boundaries. Accelerat’s reference implementation provides multiple layers of communication abstractions to support diverse use cases, from low-level transport to high-level service calls.

Primary Transport: vsock¶

The foundation of all inter-environment communication is vsock (virtual sockets over virtio). See Communication Layer (vsock) for technical details. In brief, vsock provides a reliable, low-latency channel between Bunker and Open World by offering a standard socket interface over virtio, replacing traditional TCP/IP for VM-to-VM communication with minimal overhead. However, vsock alone is too low-level for most applications; it handles only raw byte streams.

High-Level Interface: Turmux RPC¶

To simplify application development, the reference implementation provides Turmux, an RPC (Remote Procedure Call) framework inspired by Android’s Binder and Arduino Router architecture. See Reference RPC Implementation: Turmux for full details. Turmux provides a minimal router that maintains a method registry and forwards framed protobuf messages between clients and service providers. Applications in Open World can transparently call security-sensitive services registered in the Bunker. The Turmux SDK (available in Rust, Python, and C/C++) handles serialization, routing, and error handling automatically.

File Sharing via AuthFS¶

Bunkers includes a secure file-sharing mechanism built on Turmux RPC called AuthFS. AuthFS is a port of Android’s AuthFS (AOSP), adapted for Accelerat’s BCA implementation by replacing Android’s Binder with Turmux RPC and removing all Android dependencies.

AuthFS allows Open World to access files stored in or controlled by Bunker OS (and viceversa), with fine-grained per-caller access permissions enforced at the RPC layer. All file I/O operations are intercepted, validated, and logged by Bunker OS before being granted or denied.

AuthFS leverages fs-verity, a Linux kernel feature for lightweight, block-level file verification using Merkle trees. This enables efficient authentication without trusting the underlying storage. Files can be authenticated on first access and cached securely. See Reference RPC Implementation: Turmux for the AuthFS implementation example.

Summary¶

Storage Models¶

Bunker-Centric Architecture is flexible and supports different storage configurations depending on deployment requirements and available hardware. All configurations can be customized according to user preferences.

Dual Storage Configuration (Recommended):

  • Separate physical storage devices for Bunker and Open World

  • Reduces latency and I/O contention between domains

  • Bunker storage: managed exclusively by Bunker OS; handles Bunker firmware updates (TF-A), Bunker OS updates, and overall device lifecycle management

  • Open World storage: managed by Open World; each instance handles its own updates and application state independently

  • Enables independent lifecycle management for each domain

Single Storage Configuration:

  • One physical storage device shared between both domains

  • Open World accesses storage exclusively through virtio block device backend managed by Bunker

  • Bunker maintains full control over storage access, updates, and lifecycle management for the entire system

  • Open World manages its own application data and updates within its allocated storage

Flexibility and Customization:

Both configurations support independent update policies where Bunker controls its own data, firmware, software packages, and OS/Hypervisor updates, while Open World manages its own updates. Storage layout, capacity allocation, and update schedules can be customized per deployment to match specific requirements. The choice between single and dual storage configurations depends on hardware capabilities, performance requirements, and isolation needs. Most deployments should prefer the dual storage configuration to minimize contention and maximize security isolation.

Security Model and Threat Protection¶

This section provides a high-level overview of BCA’s security approach and threat model. For comprehensive security model guidance, see Security Model

Warning

Security Note: All operations involving sensitive assets flow through Bunker OS. Open World cannot:

  1. Access boot storage directly

  2. Execute privileged hypervisor operations

  3. Bypass Bunker OS’s update and verification logic

  4. Access any assets in the Bunker unless explicitly exposed by the latter

Why Open World Cannot Be Trusted¶

Open World is connected to the internet (or other semi-public networks) and potentially exposed to a wide range of external threats, such as USB and Bluetooth connectivity. The architecture treats Open World as inherently untrusted, i.e,. zero-trust, due to the fundamental challenges in securing a general-purpose Linux environment with a rich software ecosystem:

  1. Software vulnerabilities: Complex application stacks and kernel implementations create numerous attack surfaces. Vulnerabilities in either user-space applications or the kernel can be exploited to gain unauthorized access.

  2. Configuration errors: Misconfigurations in permission policies, firewall rules, access control mechanisms, and security settings can weaken isolation and allow unauthorized operations.

  3. External exposure: Open World is typically connected and accessible through multiple physical and network interfaces (Ethernet, USB, etc.), each representing a potential attack vector.

  4. Supply chain attacks: Dependencies on numerous third-party libraries and packages introduce risk; vulnerabilities in upstream projects can compromise the entire system.

  5. Physical attacks: Non-volatile storage and memory can be targeted through physical attacks, potentially exposing sensitive data or allowing unauthorized code execution.

Why Comprehensive Mitigation is Difficult

Addressing all these threats requires continuous effort to identify risks, classify threats, map attack vectors, and maintain this knowledge throughout the device lifecycle. Timely patching is often difficult or impossible due to hardware limitations, vendor support constraints, compatiblity issues, or operational complexities. In addition, a timely patch may not be a solution: before the patch is deployed, severe damage can still be caused when attacking a criticl system or stealing sensitive data. In many critical systems, achieving a high level of security while satisfying functional requirements is inherently challenging—BCA is a best-in-class solution that addresses this tension by design.

Zero-Trust Architecture for Open World

Bunker-Centric Architecture introduces a zero-trust model for Open World: no component or service running in Open World is inherently trusted. All security-sensitive operations must be isolated in Bunker OS, which is not directly exposed to the external world and is reachable only through controlled communication channels with Open World.

Deployment of Security-Sensitive Applications

Applications and services that handle sensitive data, use proprietary AI models that must be kept confidential, enforce security policies, manage cryptographic keys, or perform critical functions (e.g., plant control) must be deployed in the Bunker. These services are accessed by Open World applications exclusively through the controlled Turmux RPC interface and AuthFS, ensuring that security-sensitive operations cannot be bypassed or compromised by attacks on Open World.

Security Mechanisms¶

A properly configured deployment of Accelerat’s BCA implementation combines multiple defense-in-depth mechanisms:

  • Verified Boot Chain: Secure boot with cryptographic verification at every stage (from ROM through TF-A, OP-TEE, CLARE-Hypervisor, and Bunker OS). See Secure Boot.

  • Bootchain Hardening: Hardened U-Boot configuration and firmware parameters. See Hardening of U-Boot.

  • Integrity and Confidentiality: Bunker OS filesystems protected with cryptographic integrity and optional encryption. See Root FS Integrity and Encryption.

  • TrustZone Encryption: Hardware-backed encryption via ARM TrustZone (OP-TEE). See TrustZone and Encryption.

  • Attack-Resistant Runtime Monitoring: CLARE-Hypervisor provides kernel-level observation and enforcement of Open World behavior that is resistant to attacks, detecting unauthorized operations and policy violations with Bunker-controlled reactions.

  • Tamper-Proof Logging: Generation and secure storage within the Bunker of logs (with formats compatible with industrial security standards such as IEC 62443)

  • Hardware Monitoring: Hypervisor-assisted anomaly detection using hardware performance counters to identify suspicious execution patterns.

  • Hardware Crypto Accelerators and Enclaves: Integration with hardware-backed cryptographic helpers, TPMs (Trusted Platform Modules), and tamper detectors when available.

  • Cache and Memory Partitioning: Configuration of cache partitioning via hardware mechanisms (when available) or software helpers to mitigate cache-based side-channel attacks.

  • Segregation of Sensitive Services: Deployment of security-critical applications in isolated Bunker processes with minimal privilege and restricted resource access.

  • Additional Hardening: Platform-specific security configurations. See Miscellaneous.

Platform and Hardware Dependency

The effectiveness of BCA’s security guarantees depends on the target platform, available hardware capabilities, and vendor support maturity. Not all mechanisms are available on all platforms. For guidance on optimal BCA configuration for your specific hardware or use case, please contact us.

Protection Guarantees

With proper BCA configuration, the architecture protects against:

  • Rooting and unauthorized access to Open World

  • Malicious user applications and processes in Open World

  • Hardware-based side-channel attacks (timing, cache, speculative execution)

  • Supply chain attacks targeting third-party dependencies

  • Unauthorized OTA updates (all updates are cryptographically verified by Bunker OS)

  • Physical attacks on hardware (partially, depending on SoC capabilities and tamper detection)

  • Reverse engineering and tampering of sensitive data, keys, and intellectual property

Compliance and Regulatory Requirements

The combination of verified boot, hypervisor-assisted isolation, hardware integration, and cryptographic protection enables deployments that meet the security and integrity requirements of:

  • EU Cyber Resilience Act (CRA): Regulatory framework for connected product cybersecurity

  • IEC 62443: International standard for industrial automation and control system security

See Security Hardening for comprehensive security hardening documentation and configuration guidance.

Next Steps¶