systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling
The mkosi-initrd approach paired with systemd system extensions is a fundamental shift from expecting initrd images to be built locally on user systems to something that can be done by distribution vendors with their build system. This can allow for better QA, embracing various modern security features, and more manageable initrd assets. Zbigniew summed up his LPC 2022 talk as:
Distributions ship signed kernels, but initrds are generally built locally. Each machine gets a "unique" initrd, which means they cannot be signed by the distro, the QA process is hard, and development of features for the initrd duplicates work done elsewhere.
Systemd has gained "system extensions" (sysexts, runtime additions to the root file system), and "credentials" (secure storage of secrets bound to a TPM). Together, those features can be used to provide signed initrds built by the distro, like the kernel. Sysexts and credentials provide a mechanism for local extensibility: kernel-commandline configuration, secrets for authentication during emergency logins, additional functionality to be included in the initrd, e.g. an sshd server, other tweaks and customizations.
Mkosi-initrd is a project to build such initrds directly from distribution rpms (with support for dm-verity, signatures, sysexts). We think that such an approach will be more maintainable than the current approaches using dracut/mkinitcpio/mkinitramfs. (It also assumes we use systemd to the full extent in the initrd.)
Or for comparing and contrasting the current approach to initrd handling compared to what Red Hat / systemd developers envision, these slides are the main takeaways:
Those interested in learning more about systemd's mkosi-initrd and how the developers hope to fundamentally change initrd handling for Linux distributions, see the LPC 2022 video embedded below or this slide deck (PDF). The mkosi-initrd project is hosted on GitHub under systemd.
61 Comments
