 4️⃣ Here's the 4th installment of posts highlighting key new features of the upcoming v257 release of systemd. One of the key features of systemd we have talked about in the past years are UKIs, i.e. "unified kernel images", which is a combination of a Linux kernel, an initrd, and more into a single unified PE binary, that can be signed as a whole for SecureBoot, measured as a whole and updated as a whole. In my PoV UKIs are a central concept of securing the Linux boot process. 6 comments
…on a single kernel command line, single initrd and so on. Which is good, because it increases boot-time security and reproducibility. But it's also bad, because you cannot even use it to boot into a recovery mode or so if your install is hosed – unless you install multiple UKIs. But given that UKIs are large (they contain a full initrd, and a full set of kernel drivers after all), this typically is not what you want to do. (You could also turn off SecureBoot, … … but that is not great for security.) With systemd v257, we provide a middle ground now: UKIs may now contain multiple "profiles": multiple sets of PE sections can be combined in different ways and then labelled as different profiles. Typically this would be used to build a single UKI that contains 1 kernel and 1 initrd, but 4 different kernel command lines, which would then be combined in 4 profiles, always combining the kernel/initrd and a different command line. This way you could have one regular boot UKI profile, plus one that implements a recovery mode, another one that implements factory reset, and a fourth one that maybe boots into storage target mode. systemd-boot has been updated to synthesize multiple menu items from a single UKI – one for each profile defined in the UKI. While I'd expect that the primary use for multi-profile UKIs is to have a single set of kernel + initrd, plus a separate command line for each profile, … … the concept is actually ore flexible than that. You could also have a profile that picks a different initrd, or a different devicetree or a different boot splash or anything else that is embeddable into a UKI. And that's it for today.  @pid_eins UKIs are fine, but systemd-stub churn every release makes it more of a liability than a stable foundation to build on. Stuff like sysexts etc could poke holes in established security models similar (but restricted in scope) to how systemd poked giant holes into full disk encryption when it added DDI automount. It's a massive effort to keep up with changes and validate them and it's pretty concerning. So you might end up not doing that, and end up with vulnerabilities in your product. |
Gregory's Server
But: they do have some disadvantages. They typically imply (not strictly, but typically) that they are built on OS vendor build systems instead of locally. This is different from the status quo ante, where the initrd is typically built on the deployed system (at least on generic distros), and thus highly adapted to the local system.
UKIs being vendor-built hence means they are a lot more rigid, less flexible than the traditional way. So far this meant you'd have to settle…