/dev/SDB: Cloud-Driven Diskless Boot

• /dev/SDB is a technology for diskless booting that utilizes modular hardware and a cloud module for secure, policy-driven OS deployment.
• It employs a dual-architecture with a Hardware Module for network interfacing and a Cloud Module for authenticated OS image delivery and policy enforcement.
• The system reduces boot times through efficient HTTP transfers and in-memory OS loading, making it ideal for mobile enterprise and remote scenarios.

/dev/SDB is a software-defined standard for diskless boot that leverages existing network protocols and modular hardware-cloud architecture to enable secure, OS-assigned booting of endpoints across heterogeneous networks, including Wi-Fi and cellular. Distinct from traditional PXE and netboot technologies, /dev/SDB centralizes all OS policy and image distribution while making stateless endpoint security feasible for highly mobile enterprise scenarios (Mitra et al., 28 Jan 2026).

1. Architectural Composition

/dev/SDB comprises two principal elements: the Hardware Module (HM) and the Cloud Module (CM). The HM is a small single-board computer (SBC) outfitted with two NICs, one interfacing internally with the client PC and the other connecting externally to a network (wired, Wi-Fi, or cellular). Its key operational components are Proxy-DHCP/DHCP, TFTP server, and a DNS interceptor. The CM operates as a Flask web application backed by SQLite and optionally an NFS file store, providing authenticated OS image delivery and administrative policy enforcement. This decoupled architecture allows seamless integration at the client hardware layer while crystallizing all OS logic at the cloud tier (Mitra et al., 28 Jan 2026).

Component	Primary Functionality	Platform
Hardware Module	NIC bridging, PXE/TFTP, DNS	SBC (Raspberry Pi/Atom)
Cloud Module	Auth, image hosting, policy	Cloud VM/container

By separating physical boot mediation from remote image serving and orchestration, /dev/SDB achieves non-local, policy-driven OS delivery.

2. Boot Sequence Workflow

The end-to-end boot process is orchestrated across DHCP, TFTP, and HTTP protocols, coordinated by the HM and CM:

1. On client power-on, PXE firmware initiates DHCPDISCOVER.
2. HM responds:
   • Proxy-DHCP if upstream DHCP exists (passes through DNS/gateway), preserving network topology.
   • Local DHCP+DNS otherwise, serving its own minimal environment.
3. HM’s TFTP server delivers a small iPXE ROM (<128 KiB).
4. iPXE menu integrates HTML-form driven network setup for Wi-Fi (SSID/PSK) or cellular (APN/PIN) credentials via HM’s DNS interceptor.
5. On establishing upstream connectivity, iPXE switches to chain-loading via HTTP from the CM.
6. CM authenticates the client (username/password, MAC binding), returning an iPXE script with kernel/initramfs URLs and kernel parameters.
7. iPXE downloads the OS payload, mounts rootfs via NFS or streams a squashfs over HTTP.
8. The kernel boots entirely in RAM, with no local persistent storage invoked.

All stateful activity is brokered by the CM, and authentication is enforced prior to OS download.

3. Protocol Stack and Dataflow Mechanisms

/dev/SDB leverages standard network protocols:

• DHCPv4 + Proxy-DHCP (RFC 4578) for dynamic configuration and next-server discovery.
• TFTP (RFC 1350) exclusively for rapid transfer of the iPXE loader.
• HTTP/1.1 is used for all subsequent payload transfers and user authentication, with optional HTTPS/TLS for secure delivery.
• NFSv3 mounts are available for root filesystem access post-boot.

A unique aspect is the DNS interceptor on the HM, which sequences the end-user's network credentials acquisition prior to booting. Critically, no novel protocol is introduced; /dev/SDB synthesizes existing standards into its workflow.

Approximate model for boot-time performance (as referenced, not explicitly derived):

$$T_\mathrm{boot} \approx T_\mathrm{DHCP} + T_\mathrm{TFTP} + T_\mathrm{HTTP}(k + \mathrm{rfs}) + T_\mathrm{kernel}$$

where $k$ denotes kernel/initrd size and $rfs$ is the rootfs transfer time (Mitra et al., 28 Jan 2026). Typical simulated boot time is <$3$ s for a $4$ MiB image.

4. Authentication, Security, and Policy Enforcement

Security is achieved through central authentication, in-memory boot, and network isolation mechanisms:

• CM authenticates users via username/password and MAC address before OS delivery.
• Proxy-DHCP poisoning is precluded as the HM is physically isolated and the sole responder on the client-internal link.
• No persistent storage exists at the endpoint: all runtime state, including malware, is purged on shutdown.
• Image and bootloader signing are anticipated for future releases; currently, security relies on HTTPS/TLS and Flask-backed credential verification.
• Policy is strictly enforced within CM, which dynamically generates user-specific iPXE scripts and controls allowable OS images.

This security posture supports stateless, policy-compliant endpoint operation in hostile or variable network environments.

5. Empirical Evaluation and Comparative Analysis

/dev/SDB was evaluated in GNS3 simulator settings with QEMU targets and Alpine-based HM emulation. OS images (KolibriOS, TinyCore, Alpine) were served to three stateless endpoints, booting in under three seconds per device. No direct wireless or cellular throughput metrics were reported; simulations omitted link variances and external bandwidth (Mitra et al., 28 Jan 2026). Authors note that under comparable payload sizes, /dev/SDB halves boot time versus traditional PXE+TFTP, primarily due to HTTP and RAM-resident NFS optimizations.

A plausible implication is that real-world link variability (latency, loss) will become the dominant factor, affecting $rfs$ and, thus, $T_\mathrm{boot}$. Unlike legacy netboot, /dev/SDB allows boot provenance and traffic to be cloud-routed, facilitating remote work scenarios.

6. Implementation, Scalability, and Deployment Modalities

Deployment requires minimal hardware overhead—a dual-NIC SBC suffices for HM, while CM can be a cloud VM/container with standard HTTP and NFS payload services.

• HM: Alpine Linux, dnsmasq, TFTP, Flask, iPXE ROM (128 MiB RAM required).
• CM: Flask, SQLite/RDBMS, HTTP server, optional NFS.

Clustered multi-AZ CM deployment is supported, with object storage or CDN-based OS distribution for scaling. HMs can be ubiquitously embedded or physically attached to client machines. Redundancy considerations focus on CM’s back-end storage (active–passive failover); HM units are individually isolated, inexpensive, and easily replaced.

Practical contexts include corporate hot-desking, stateless kiosks, shared workstations in co-working spaces, and field recovery endpoints via 4G/5G. Data and runtime state are never locally persisted.

7. Limitations and Prospective Enhancements

Current /dev/SDB iterations use HTTP without mandatory TLS and lack cryptographic signature chains for bootloader and OS images. The authors propose UEFI Secure Boot, image signing, and mandatory certificate pinning for subsequent revisions. Real measured performance over congested or high-latency links and satellite connections (e.g., Starlink) remains open.

A plausible implication is the necessity for loader-stage formal verification and peer-to-peer HM caching as cloud usage scales. The transition to hardened hardware appliances for HM is anticipated to reduce attack surfaces.

In summary, /dev/SDB establishes a novel framework for diskless, authenticated, policy-defined OS booting over arbitrary IP networks, making fully stateless and secure endpoint delivery feasible for globally distributed users in both enterprise and ad-hoc scenarios (Mitra et al., 28 Jan 2026).