Storage Models

Summary

BCA reference designs support both single-storage and dual-storage configurations. The architecture is flexible so that multiple storage models can be accommodated, but the security model requires that boot artifacts and firmware updates remain under the control of the Bunker OS. This file outlines the reference patterns, trade-offs, and the impact on update model. The high-level storage philosophy is documented in the System Overview storage section.

Principles

  • The boot partition (firmware, TEE, hypervisor, kernel images) must be controlled and verified by Bunker OS as part of the root-of-trust.

  • Flexible deployment: single or multiple physical storage devices are supported depending on cost and performance trade-offs.

  • Open World isolation: When only a single physical storage device is present, Open World accesses storage via a virtualized interface (virtio-blk) served by the Bunker OS. For production deployments we recommend dual (or multiple) physical storage devices so that Open World can access its own device directly; dual storage provides better performance and stronger isolation.

Reference Modes

Single Storage

In single storage mode the device exposes one physical storage device (SD, eMMC, NVMe). Bunker OS acts as the storage controller and provides a virtio-backed block device to Open World. This simplifies hardware requirements (single media) and is convenient for development and low-cost deployments, but it has performance limitations compared to direct passthrough access.

Important

Key points:

  • Open World sees a virtual block device (virtio-blk) served by Bunker OS.

  • I/O is multiplexed by the Bunker, so Open World may experience higher latency under load.

  • Boot partition, kernels and signed bundles are verified and controlled by Bunker OS.

Dual / Multiple Storage

In dual or multiple storage configurations separate physical devices are used for Bunker OS and Open World (for example, eMMC for Bunker OS and separate eMMC/NVMe/SD for Open World). This provides higher throughput, parallel boot, and stronger isolation.

Important

Key points:

  • Both Bunker OS and Open World have direct access to their own physical storage.

  • Parallel boot and improved I/O performance.

  • Boot partition, kernels and signed bundles are still verified and controlled by Bunker OS.

Update & Boot Control Model

Open World is responsible for managing its own application and rootfs updates, typically using an A/B partition scheme where new versions are written to an inactive partition and then swapped over. Bunker OS, in contrast, is responsible not only for its own updates but also for boot-related artifacts (hypervisor, OP-TEE, signed kernels).

The reference design uses RAUC as the update mechanism for both domains. RAUC is already integrated with U-Boot in the reference implementation and provides atomic, signed updates with rollback capability. Open World typically employs a simple A/B partition scheme, while Bunker OS uses a 3-partition model: A/B immutable partitions (both signed and subject to integrity and confidentiality protection) plus a writable data partition for runtime state. You may substitute your own update tool if required, but RAUC is the reference implementation and is pre-integrated in the meta-layers. See Update Management for integration details and update flows.

Bunker OS uses RAUC to perform signature verification (via OP-TEE or HSM) and controls the activation of all updates. Additionally, boot partition images are signed and validated at boot time by the secure boot mechanism, providing defense in depth against tampering. See Boot Flow for secure boot details and Update Management for RAUC update workflows.

Reference partition examples

These partition layouts are used in the reference design and are configured in the meta-layers. You can customize them for your deployment, but modifications require rebuilding and reconfiguring the Yocto recipes.

Open World example (A/B):

/dev/mmcblk1p1  StartLBA: 8192   -> U-Boot environment
/dev/mmcblk1p2  StartLBA: 114688 -> rootfs A
/dev/mmcblk1p3  StartLBA: 139264 -> rootfs B

Bunker OS example (adds boot partition and separate A/B):

/dev/mmcblk0p1  StartLBA:   8192 -> boot partition (signed bundle)
/dev/mmcblk0p2  StartLBA: 114688 -> U-Boot environment
/dev/mmcblk0p3  StartLBA: 139264 -> rootfs A (signed)
/dev/mmcblk0p4  StartLBA: 475136 -> rootfs B (signed)

See the RAUC integration guide for an example U-Boot setup.

Note

Storage configuration and hypervisor: If you change the storage device assignment or layout (for example, moving from single to dual storage or swapping storage device assignments), the hypervisor configuration must also be updated to reflect the new device topology. This requires rebuilding the hypervisor with the updated device tree and configuration.

AuthFS and secure transfer

Bunker OS generally does not access the internet directly. Instead, Open World (which has network connectivity) downloads or uploads artifacts and then transfers them to Bunker via authenticated channels. In the reference design we use an authenticated file-exchange primitive (AuthFS) to ensure integrity and confidentiality when moving files between domains. See Networking for the AuthFS description and Update Management for the update integration with RAUC.

Guidance and trade-offs

  • Use single storage for development, testing and cost-constrained systems where peak I/O is not critical.

  • Use dual or multiple storage for production, performance-sensitive, or latency-critical deployments.

  • Always enforce signed images and hardware-backed keys for boot-critical partitions.

  • Design update workflows so that Bunker controls activation of boot/factory images and can validate signatures inside a trusted execution environment.

  • All partition, RAUC, and meta-layer configurations are customizable. Refer to the Meta Layers Reference for recipe customization and to Update Management for RAUC and update integration details.

Where to go next