Networking¶

Network Isolation Model¶

Bunker-Centric Architecture implements network isolation by default. This is a key security boundary. In reference designs, the Bunker-Centric Architecture isolates the trusted Bunker OS from the network: the Bunker OS has no direct internet access while the Open World domain retains internet connectivity. Inter-domain communication is performed over vsock, typically using Turmux RPC as the higher-level RPC protocol.

This model ensures:

Security: Bunker OS is isolated from external threats
Control: Open World communicates with Bunker OS only through the communication channel
Observability: Bunker OS controls what external services are accessible
Simplicity: Clear security boundary — network isolation of trusted domain

Inter-Domain Communication¶

All communication between Open World and Bunker OS occurs over vsock (VM sockets). There are two levels of abstraction:

Raw vsock: Low-level socket communication
Turmux RPC: Higher-level RPC protocol for simplified implementation

For most use cases, Turmux RPC is recommended as it provides a cleaner abstraction and handles serialization, error handling, and method routing automatically. Raw vsock is available for advanced scenarios requiring custom protocols.

See System Overview for comprehensive communication overview and architecture details.

vsock Transport¶

vsock (VM sockets):

vsock is a virtio-based inter-VM transport that leverages shared memory for high performance, provides reliable ordered delivery, and uses a (CID, Port) addressing model. See the Linux man pages for implementation details: Virtio-based inter-VM communication (Linux man pages).

vsock Addressing:

(CID, Port)

CID:
- 2 = Bunker OS (host)
- 3 = Open World (guest)

Port: Application-specific service identifier

Raw vsock Example (Low-level socket communication):

import socket

# Open World application using raw vsock
sock = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)

# Connect to Bunker OS service
# CID=2 (Bunker OS), Port=5000 (custom service)
sock.connect((2, 5000))

# Send custom protocol data
request = b'custom_binary_data'
sock.send(request)

# Receive response
response = sock.recv(4096)
sock.close()

Kernel Configuration:

vsock is enabled by default in Bunker Development Framework (BDF) kernel recipes. If you customize kernel recipes, ensure these configurations are enabled:

# In kernel config
CONFIG_VSOCK=y
CONFIG_VSOCK_LOOPBACK=y

Turmux RPC¶

Turmux RPC is a higher-level RPC protocol built over vsock that provides a cleaner abstraction for inter-domain communication. It uses protobuf for serialization, enabling strongly-typed message definitions and efficient binary encoding. The protocol handles method routing, error propagation, and automatic serialization, simplifying implementation compared to raw vsock. Method calls are routed based on service names and method identifiers, making it ideal for structured service-oriented communication.

Turmux RPC Example:

import turmux_python
from ping_pb2 import PingRequest, PingResponse

# Open World client connecting to Bunker OS service over vsock
client = turmux_python.TurmuxClient.connect_vsock(cid=2, port=5000)

# Create and serialize protobuf request
ping_req = PingRequest(number=42, flag=True)
response_bytes = client.call("ping", ping_req.SerializeToString())

# Deserialize protobuf response
ping_resp = PingResponse()
ping_resp.ParseFromString(response_bytes)
print(f"Got response: number={ping_resp.number}, flag={ping_resp.flag}")

See Reference RPC Implementation: Turmux for detailed Turmux RPC protocol documentation and examples.

Accessing External Services¶

For Bunker OS to Access External Services

Bunker should be treated as the provider of security-sensitive services and, in normal operation, should not require external connections. There are, however, valid scenarios where the Bunker OS must interact with external services - for example, uploading logs, sending remote attestation bundles, or retrieving signed firmware images.

The recommended pattern is a service-based RPC exchange: implement a Turmux RPC service/gateway in the Open World domain that has internet access, and have the Bunker OS communicate with that service over vsock. The Open World side performs network-facing operations on behalf of Bunker and returns results via the RPC channel. Crucially, Open World must always be considered untrusted: any payload originating from or passing through Open World should be protected for confidentiality and integrity before being consumed by the Bunker OS.

To support secure payload exchange we provide two primitives and a set of ready-made services:

AuthFS — an authenticated filesystem interface that lets Open World deliver files to Bunker with integrity guarantees (file contents and metadata are verifiable by the Bunker). This protects against tampering when files are sourced from the internet and proxied by Open World.
Pre-built RPC services — common gateway services that handle downloading/uploading payloads and perform envelope encryption so that payloads stored or transmitted via Open World remain confidential and integrity-protected. Use these services to move sensitive artifacts (logs, attestation bundles, firmware) without exposing plaintext to the untrusted domain.

Security guidance

Treat Open World as non-trusted; encrypt and sign any critical payloads before transit.
Use authenticated channels and message-level integrity (protobuf envelopes + signatures or AEAD encryption).
Minimise the Bunker-exposed attack surface: where possible, prefer push-only flows (Bunker pushes encrypted logs) or strictly validate/whitelist incoming artifacts.

Advanced: Ethernet Interface for Bunker¶

In specific scenarios it may be necessary to provide the Bunker OS with direct network access. This is not recommended for the reference design because it widens the attack surface and exposes the security partition to external threats.

There are cases where exposing a network interface to Bunker OS is justified. For example, a board with two physical interfaces where one is assigned to Open World (IT, controlled) and the other to Bunker OS (OT, trusted by construction). In such deployments the security model is relaxed intentionally and relies on the OT network being trusted by design. In other cases, a trusted network may be shared with the Bunker OS after careful evaluation.

All these configurations require careful analysis and additional hypervisor and kernel configuration (device assignment, network isolation rules, virtio drivers, and corresponding firewall policies). These changes are outside the reference design and require bespoke engineering, validation, and risk assessment.

For assistance with advanced networking configurations and threat analysis, contact our support team at support@accelerat.eu.