The Many Paths to init, Part 5: Unifying Themes

• UEFI Secure Boot (PCs/Servers): This standard is designed to protect the user from malware like bootkits. It uses a database of keys in the firmware to verify EFI applications. Crucially, it is designed to be flexible; users can disable it or enroll their own keys to run any OS they choose, preserving user control over the hardware.

• Hardware-Fused Boot (Embedded/IoT): In the embedded world, the threat model shifts to protecting the manufacturer from unauthorized firmware. Mechanisms like NXP’s High Assurance Boot (HAB) establish an immutable root of trust by permanently burning a hash of the manufacturer’s public key into one-time-programmable eFuses on the SoC. On a “closed” device, the Boot ROM will refuse to execute any code that isn’t signed by the manufacturer, creating a non-bypassable lockdown.

• IBM Z Secure Boot (Mainframes): The mainframe threat model is focused on enterprise-grade compliance and auditability. Here, public keys are uploaded to the Hardware Management Console (HMC) and explicitly assigned to specific Logical Partitions (LPARs). The firmware will only boot an LPAR with code signed by its assigned keys, providing a strict, centrally managed chain of trust essential for high-security environments.

Ensuring Resiliency with Atomic Updates

A failed update can render a device unusable. To prevent this, modern systems employ atomic update strategies that ensure an update is either fully completed or not at all, always leaving the system in a bootable state.

• The A/B Partitioning Model (State-Switching): This is the dominant strategy in the mobile and embedded worlds. The system has two full sets of OS partitions (slot A and slot B). While running from the active slot (A), an update is written to the inactive slot (B) in the background. Once complete, the bootloader is instructed to switch to slot B on the next reboot. If the new slot fails to boot, the bootloader automatically reverts to the original slot A, ensuring the device remains operational. This robust model is used by Android Seamless Updates and embedded frameworks like RAUC. Its main drawback is the storage overhead of duplicating the OS partitions.

• The Transactional Update Model (State-Generation): For servers and modern desktops, a more storage-efficient model has emerged, exemplified by rpm-ostree (the technology behind Fedora CoreOS and Silverblue). This system treats the OS as a versioned, git-like repository. An update does not modify the running system; instead, it “checks out” a new filesystem tree into a new directory. The bootloader configuration is then atomically updated to point to this new deployment. The old deployment remains untouched on disk, allowing for instant rollback by simply changing the bootloader’s default entry. This “State-Generation” pattern is more flexible and storage-efficient, making it ideal for server and cloud environments.

Conclusion

The Linux boot process is a rich tapestry of specialized adaptations. From the atomic UKIs on modern servers to the multi-stage ascent of embedded SoCs, each platform has forged a unique path from power-on to init. This diversity is a testament to the kernel’s flexibility. As technology evolves, we see a convergence of ideas: the principles of verifiable boot artifacts and transactional, image-based updates are becoming the new standard across all domains, pointing to a future of Linux systems that are simpler to manage, more resilient to failure, and provably secure from the very first instruction.