I didn’t read the rest of the proposal yet, but the part about sd-boot is divorced from reality.
The upstream UKI specification is being extended regularly with new features, and systemd-boot and systemd-stub are extended with new features regularly.
https://github.com/systemd/systemd/blob/main/NEWS is the authorative source.
I asked an llm to filter the list for sd-boot over the last few releases. FWIW, here is its output:
v261 (in development)
- Will never auto-boot a non-default UKI profile (prevents accidental boots into alternative profiles after a timeout expiry).
v260
- Boot menu timeout configurable via SMBIOS Type 11 string io.systemd.boot.timeout=.
- New LoaderEntryPreferred setting, similar to LoaderEntryDefault but takes boot-assessment into account and skips entries with tries-left=0.
v259
- Log levels supported, set via log-level= in loader.conf or SMBIOS Type 11 io.systemd.boot.loglevel=.
- loader.conf gained secure-boot-enroll-timeout-sec= for SecureBoot key enrollment timeout.
- Boot Loader Specification Type #1 entries gained a profile field for selecting a profile in multi-profile UKIs.
- (Removal: TPM 1.2 support dropped.)
v258
- Two new BLS Type #1 stanzas: uki and uki-url (the latter for HTTP/HTTPS-hosted UKIs).
- Looks for SMBIOS Type #11 io.systemd.boot.entries-extra= to synthesize additional boot menu entries.
- loader.conf gained reboot-on-error setting (reboot vs. show menu when boot fails).
- loader.conf gained secure-boot-enroll-action (reboot or shut down after auto-enrollment).
- Honors new LoaderSysFail EFI variable to pick a fallback entry on firmware-reported system failure.
- Sets LoaderTpm2ActivePcrBanks EFI variable advertising the available TPM2 PCR banks.
v257
- Menu now reacts to volume up/down rocker presses the same as arrow up/down (useful on phones).
v256
- Passing additional kernel cmdline via SMBIOS Type #11 io.systemd.boot.kernel-cmdline-extra (now also applies to BLS Type #1 entries, not just stub).
- Automatic SecureBoot enrollment gained dbx enrollment support (previously db/KEK/PK only), plus UEFI “Custom” and “Audit” modes.
v255
- New hotkeys “B” (reboot) and “O” (poweroff) in the boot menu, with auto-reboot/auto-poweroff loader.conf options to show them as menu entries.
- New menu-disabled value for set-timeout (fully disables menu including hotkey).
- Measures content of loader.conf into TPM2 PCR 5.
- systemd-boot and systemd-stub now use distinct SBAT project keys for independent revocation.
- No longer loads unverified DeviceTree blobs under UEFI SecureBoot (CVE fix: GHSA-6m6p-rjcq-334c).
v254
- gnu-efi build dependency dropped; pyelftools is now used to perform ELF→PE relocations at build time.
v253
- Passes random seed directly to the kernel via the LINUX_EFI_RANDOM_SEED_TABLE_GUID config table (seeds the RNG very early).
- Passes a disk-backed random seed even under SecureBoot when EFI RNG protocol (or prior bootloader seed) is available.
- systemd-boot-system-token.service renamed to systemd-boot-random-seed.service and now always refreshes the ESP seed.
- Seed inputs handled with a domain- and field-separated hashing scheme.
- random-seed-mode option removed (a system token is always required).
- Can now be loaded from outside the ESP (e.g. direct kernel boot under QEMU, embedded in firmware).
- Parses SMBIOS info to detect virtualization (skip irrelevant warnings, etc.).
- New if-safe mode that performs auto SecureBoot enrollment only when “safe” (currently: in a VM).
v252
- UEFI monotonic boot counter mixed into the updated random seed file (extra entropy).
- EFI mixed-mode boot supported (64-bit kernel over 32-bit UEFI firmware).
- (Experimental) Automatic SecureBoot key enrollment from files staged on the ESP, in force or manual modes.
In fact, this list gives a misleading impression, since it covers sd-boot only. sd-boot is actually just the menu, so there isn’t that much to do. The interesting stuff happens in sd-stub, i.e. the part that is attached to the kernel image to form an UKI.
- Although sd-boot is a light and trivial bootloader, it has not been widely tested or fuzzed
It is fairly widely used. The code is fuzzed through oss-fuzz. (Not as extensively as it should be. Nevertheless, a blanket statement that is is not fuzzed is unsubstantiated.)
- Long term maintenance of more than one bootloader would result in a lack of parity and added technical debt
Maybe. One could also argue that maintenance of systemd is “light and trivial” and not much of an issue…
- Potential expansion to other architectures would necessitate a compatible bootloader anyway.
This one is somewhere between misleading and wrong. sd-boot supports multiple architectures (7 atm.) and new ones could be added. The majority of code is portable C. A bigger limitation is that sd-boot only supports UEFI architectures. But if we expand to new architectures, they are very likely to support UEFI.
It’s actually good to make a comparison with the alternative projects in a proposal, but please try to be factual.