FAQ & Support

Getting Help

Before Contacting Support:

  1. Check this FAQ

  2. Review relevant documentation section

Contact Accelerat:

Frequently Asked Questions

These are the most frequently asked questions from system architects and developers integrating Bunker-Centric Architecture.

Note

Flexibility and Customization: All BCA policies, configurations, and security mechanisms described here are flexible and can be customized to your specific deployment requirements. Hardware capabilities, threat models, performance constraints, and operational needs vary widely. If you have questions about adapting BCA to your use case or need guidance on configuration options, please contact us.

Q: What interfaces does Bunker OS have access to?

A: Bunker OS has, commonly, restricted access to only the interfaces and devices necessary for security services:

  • Crypto accelerators: For cryptographic operations

  • Storage device: For Bunker OS filesystem and data persistence

  • TPM/Tamper detectors: When available on the platform

  • Selected hardware components: Configuration-specific (e.g., serial console, certain GPIO pins)

Bunker OS does not have direct access to:

  • Network interfaces

  • USB ports

  • General-purpose I/O

  • Ethernet or WiFi hardware

When Bunker OS needs to communicate with external services (upload logs, fetch policies, etc.), it sends requests through a secure tunnel via Open World. Accelerat provides services for common patterns like secure update downloading and telemetry upload. See Services API Reference.

—

Q: What happens if Open World crashes or is compromised?

A: Open World can crash, hang, or be compromised by malicious code - this is expected in the threat model. Recovery depends on configuration:

  • Open World crash: Hypervisor detects the failure. If configured for auto-recovery, Open World restarts automatically (without affecting Bunker OS).

  • Open World compromise: Bunker OS remains isolated and continues running. Services relying on Open World may be unavailable until Open World is recovered or restarted.

  • Anomaly detection: Bunker OS can detect suspicious behavior in Open World through hypervisor monitoring of performance counters and system calls. Depending on policy, Bunker OS may log the anomaly and/or request a reboot.

  • Hardware watchdog: An optional hypervisor-configured watchdog can reset Open World or the entire board on timeout. This is useful for systems requiring guaranteed recovery from stuck states.

This isolation is the core security property of BCA - a compromise of Open World does not compromise Bunker OS or its services.

—

Q: Can I modify the hypervisor at runtime?

A: No. The hypervisor and its configuration are statically defined and immutable after boot. They are cryptographically verified at boot time. Attempting to modify the hypervisor or its configuration causes boot failure.

This immutability provides three critical guarantees:

  • Traceability: Hypervisor behavior is deterministic and known at deploy time

  • Security: No runtime modifications can weaken isolation or domain boundaries

  • Safety: Configuration is stable throughout the device lifetime

If you need to change hypervisor configuration (memory partitions, CPU assignment, device mappings, etc.), you must perform a full hypervisor rebuild and redeploy through OTA update or bootloader reconfiguration.

—

Q: How do I add custom services in Bunker OS?

A: Custom services in Bunker OS are added through the Bunker Development Framework (BDF):

  1. Define your service in BDF recipes (meta-bunker-linux-core layers)

  2. Add service to systemd or init scripts

  3. If Open World needs to communicate with your service, implement a Turmux RPC interface. See Reference RPC Implementation: Turmux.

  4. Build new Bunker OS image using BDF

  5. Deploy via RAUC update (if already in production) or direct bootloader installation

See Custom Service Development and Building Custom Images for detailed instructions.

—

Q: Can I use dual storage?

A: Yes, if your hardware supports it. Dual storage offers better performance and a more robust security model. See Storage Models.

—

Q: Can I add more CPUs to Open World?

A: Yes, but this requires a hypervisor rebuild. CPU assignment to each domain (and thus core count) is determined at hypervisor compile time through:

  • Device tree configuration: Which cores to assign to which domain

  • Hypervisor compile-time settings: Domain memory and resource partitions

Increasing CPU count, changing RAM partitioning, or adjusting device assignments all require rebuilding and redeploying the hypervisor. See platform guides: AMD UltraScale+ Family, NXP i.MX93 Family or ST STM32MP2 Family.

—

Q: How do I build custom Bunker OS and Open World images?

A: Use the Bunker Development Framework (BDF), which provides Yocto layers for both partitions. All customization such as adding services, modifying configurations or changing software stacks goes through BDF recipes and layers. See Building Custom Images.

—

Q: What’s the difference between Bunker OS and Open World?

A:

Aspect

Bunker OS

Open World

Purpose

Security-critical services, policy enforcement

User applications, general workloads

Trust Level

Trusted (protected)

Untrusted (may be compromised)

Privilege

Elevated (EL1, hypervisor-protected)

Normal (VM, EL1)

Storage Access

Direct, isolated partition

Depends on storage model: direct partition (dual storage) or via virtio (single storage, Bunker OS-controlled)

Network Access

None (uses RPC for outbound services)

Full (direct Ethernet, WiFi, etc.)

Size

RAM: ~128 MB | NV Storage: ~32 MB (rootfs)

RAM: Depends on configuration | NV Storage: Depends on applications, data, and configuration. Size strongly depends on your deployment requirements.

Customization

Via Bunker Development Framework (BDF, Yocto-based). See Versioning & Release Strategy for Yocto compatibility.

Via Bunker Development Framework (BDF, Yocto-based). See Versioning & Release Strategy for Yocto compatibility.

Kernel

Minimal, hardened Linux

General-purpose Linux

—

Q: How do I monitor Open World from Bunker OS?

A: Bunker OS can monitor Open World through hypervisor-provided mechanisms:

  • Resource usage: CPU cycles, memory allocations, cache behavior

  • System calls: Track Open World syscalls for policy enforcement

  • Performance counters: Detect anomalies through hardware performance monitoring

  • Logs and RPC calls: Open World services report events and statistics to Bunker OS through Turmux RPC

  • Unexpected behavior: Hypervisor can detect policy violations and alert Bunker OS

Use the Accelerat dashboard, CLI tools, or implement custom monitoring services in Bunker OS. See Runtime Monitoring and Logging.

Performance & Optimization

For questions about optimizing boot time, network throughput, power consumption, or other performance metrics, please contact support. Support team can provide platform-specific tuning recommendations based on your hardware configuration and workload requirements.

Security Best Practices

For comprehensive security guidance, see System Overview (Security Model and Threat Protection section) and Security Hardening.

Common topics covered in the security documentation:

  • Verified boot chain and secure boot configuration

  • Hypervisor-level isolation and monitoring

  • Cryptographic key management

  • OTA update verification

  • Physical security and tamper detection

  • Hardware security features (TPM, TrustZone, etc.)

If your specific security concern is not covered in the documentation, please contact support.

Next Steps