/dev/SDB: Software Defined Boot -- A novel standard for diskless booting anywhere and everywhere

A computer is nothing but a device that processes the instructions supplied to it. However, as computers evolved, the instructions or codes started to be more complicated. As computers started to be used by non-technical people, it became imperative that the users be able to use the machine without having underlying knowledge of the code or the hardware. And operating system became the backbone for translating the inputs from the user to actual operation on the hardware. With the increasing complexity and the choices of operating system, it became clear that different groups of people, especially in an enterprise scenario, required different operating systems. Installing them all on a single machine, for shared computers became a difficult task, giving rise to network-based booting. But network-based booting was confined to only wired connectivity, keeping it restricted to very small geographical areas. The proposed system, /dev/SDB, is aimed at creating a standard where any user, anyone on the globe, can access the operating system authorized to them without having to be on the corporate network. It aims to offer the same over Wi-Fi as well as cellular connectivity, ensuring employees can truly work from anywhere, while following the policies for operating systems and without redundant hardware.

💡 Research Summary

The paper proposes a new standard called /dev/SDB (Software Defined Boot) that enables disk‑less booting of enterprise workstations over any type of network connection—wired Ethernet, Wi‑Fi, cellular, and even future satellite links. The motivation is the growing need for remote work and the fact that different employees require different operating systems (OS) for their roles. Traditional network boot (PXE) is limited to wired LANs, which restricts flexibility and increases hardware redundancy because each machine still carries a local storage device that merely holds the OS image.

System Architecture
The solution consists of two complementary modules:

1. Hardware Module – a lightweight single‑board computer (SBC) running Alpine Linux. It provides two network interfaces: one connects internally to the target PC (via PCIe or a short UTP cable) and the other connects outward to the Internet through Wi‑Fi, a cellular modem, or Ethernet. The SBC acts as a bridge and runs a DHCP server (or a proxy‑DHCP if an upstream DHCP server exists), a TFTP server, a DNS server that resolves all queries to itself, and a Flask‑based web service that presents iPXE‑compatible configuration forms. When the target PC powers on, it enters the PXE environment, receives a DHCP offer from the SBC, and downloads a custom iPXE bootloader via TFTP. The bootloader then contacts the SBC’s DNS, which redirects the request to the SBC’s web service. The user is prompted to enter Wi‑Fi credentials or cellular APN details; once the SBC obtains Internet connectivity, it forwards the client to the cloud module.

2. Cloud Module – a web application backed by an SQLite database, file storage, and optionally an NFS server. Administrators can upload OS images (kernel, initrd, boot scripts) and assign them to individual users. User management includes creating accounts, deleting them, and linking each account to a specific OS image. Authentication is performed via username/password, and successful logins trigger the cloud server to stream the assigned OS image to the client over HTTP or NFS. All authentication attempts are logged together with the client’s MAC address for audit purposes.

Implementation and Evaluation
The authors built a prototype in the GNS3 network simulator. The hardware module was instantiated from an Alpine Linux image with 128 MB RAM, while the target PCs were QEMU virtual machines with 256 MB RAM and no local storage. Three virtual PCs simulated different employees. The cloud module ran on the host machine outside the simulated network. The experiment demonstrated that the SBC could automatically detect the presence or absence of an upstream DHCP server, configure itself accordingly, and guide the client through Wi‑Fi or cellular configuration without any pre‑installed OS. After authentication, each virtual client received the correct OS image and booted entirely in RAM, confirming the feasibility of a completely disk‑less workflow.

Related Work
The literature review covers classic PXE, UEFI Secure Boot, iPXE extensions (HTTP, iSCSI, TLS), and recent research such as FLEX‑IoT, Colaboot, M2, and proprietary solutions like Dell BIOSConnect and Windows 365 Boot. The authors argue that while many works explore network boot in data‑center or IoT contexts, none address the combination of (a) multi‑modal connectivity (Wi‑Fi, cellular, satellite) and (b) per‑user OS assignment in an enterprise setting.

Critical Analysis
The proposal is innovative in its ambition to unify wired, wireless, and cellular boot paths under a single standard. The use of a lightweight SBC as a “boot gateway” is practical for environments where the client hardware cannot be trusted to have a functional network stack. By handling DHCP, TFTP, and DNS locally, the system can operate even on networks that block PXE traffic. The iPXE script‑driven UI for Wi‑Fi/Cellular credentials is a clever way to collect network parameters before any OS is present.

However, several concerns arise:

• Security – Authentication relies on username/password and MAC‑address logging; MAC spoofing is not mitigated. iPXE’s TLS support is limited to 1.2 with older cipher suites, exposing the boot process to downgrade attacks. The paper mentions TPM‑based secure boot in related work but does not integrate it into the prototype.
• Scalability – The prototype uses a single SBC and a single HTTP/TFTP server. In a real enterprise with thousands of concurrent boots, the SBC becomes a bottleneck, and the central server would suffer from massive image‑distribution traffic. The authors cite P2P‑style distribution (e.g., BitTorrent‑like) but do not implement it.
• Performance – Streaming a full OS image over cellular links can be latency‑heavy; the paper does not quantify boot times under varying bandwidth conditions. Memory requirements for a full RAM‑disk boot are modest in the demo (256 MB) but would be substantially higher for modern desktop OSes.
• Reliability – The SBC must survive power loss and retain its configuration. Firmware updates, secure boot of the SBC itself, and fallback mechanisms are not discussed.

Future Work
The authors suggest extending the design with TPM‑based boot integrity verification, adopting TLS 1.3, integrating a CDN/P2P hybrid for image distribution, and conducting pilot deployments in real corporate networks. Addressing these points would be essential before the standard could be considered for wide adoption.

Conclusion
/​dev/SDB presents a compelling vision for a universal, software‑defined boot mechanism that eliminates local storage, supports any network medium, and enforces per‑user OS policies. The prototype validates the core concept, but substantial engineering effort is required to harden security, scale to enterprise loads, and ensure reliable operation across diverse hardware platforms. If these challenges are met, the standard could significantly simplify OS management in the era of pervasive remote work.