Component

bootctl, systemd-boot

Is your feature request related to a problem? Please describe

EFI unified kernel images (as specified https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images) are a way to bundle a vmlinuz, initrd and cmdline in a self-contained file. The key benefit of this approach is that the cryptographic signature for SecureBoot covers all components at once.

The downside of it, however, is the relative lack of flexibility compared to a situation where there are install specific locally generated initrd/cmdlines. The lack of flexibility of a pre-generated initrd can be mitigated sufficiently using systemd system extension images (https://www.freedesktop.org/software/systemd/man/systemd-sysext.html) which augment the initrd contents. AFAICT, there is no similar mitigation for the the kernel cmdline to allow use of a varying set of kernel options (provided they are still host install agnostic).

Consider a default distro installation might have a embedded cmdline of console=ttyS0 console=tty0 quiet rhgb. This is sufficient for the 99% of the time when the distro is working nominally, however, when things go wrong it can be limiting. For example if there is a bad kernel, the user may wish to boot with console=ttyS0 console=tty0 debug to maximise the visibility of initial kernel messages. Such a customization cannot be done without loosing the coverage of the SecureBoot signature, since naturally a bootloader cannot safe allowing the user to enter arbitrary unchecked cmdline options. Disabling SecureBoot in order to supply different cmdline options to aid debugging a failed boot is not to be done lightly, as it raises questions over the integrity of the OS when SecureBoot is subsequently re-enabled.

IOW, it is desirable to be able to temporarily boot with an alternative, but still trustworthy, pre-defined cmdline for the purposes of debugging.

Describe the solution you'd like

I'd like to suggest that the unified kernel images have some mechanism to express alternate cmdline entries. Such command lines would be covered by the SecureBoot signature still, and thus their contents would need to not open any inadvertent holes in kernel integrity just like the primary cmdline.

I'm not suggesting changing semantics of the existing .cmdline section, since that would cause backwards compatibility challenges. Regardless of solution, a bootloader would still default to using the existing .cmdline section in all scenarios. Any additional entries would merely be used to provide an opt-in to use of an alternative cmdline via some simple bootloader UI choice.

A targeted single use case mechanism, could be to define a new optional section .cmdline_verbose that merely allowed 1 single alternative cmdline to be presented, whose semantics are defined to be a Verbose boot.

A broad general purpose mechanism, could be to define a new optional section '.cmdline_profiles' whose content is structured to allow many named "profiles" to be selected between, each providing a custom cmdline

   "profile-name1{nul}cmdline1{nul}profile-name2{nul}cmdline2{nul}....."

The "profile-name" would be used by a bootloader to present a choice of cmdlines to boot with.

Describe alternatives you've considered

Today the only known approach is to simply pre-generate multiple unified kernel images, using the same vmlinuz and initrd contents, and different cmdline contents. eg vmlinux-$VER.efi and vmlinux-verbose-$VER.efi This is functionally viable, and bootloaders allow the user to select between the normal and verbose variants. The downside is the cost in disk space, both for the local install, and for the OS distros having to ship multiple full kernel images. The suggested embedding of multiple cmdlines is intended to achieve the same result, but eliminate the duplicate storage at all stages, albeit with the need for bootloaders to be enhanced to support this logic. The storage overhead may not be acceptable to people wishing to minimize their cloud disk image size, nor to the distro whose packages get larger with every cmdline variant they need to support.

ANother alternative would be for the bootloaders to allow editting of the cmdline even when SecureBoot is active, and have the bootloader validate each supplied option against a list of permissible options. This could involve the EFI unified image containing a section .cmdline_permissible_options, which contained option-1{nul}option-2{nul}option-3{nul}..... Any combination of permissible options in any order would be valid to use, with strict string equality matches performed. This would allow simple options which don't need values, and even those taking values provided the set of permissible values is finite and predictable. It wouldn't allow for arbitrary user chosen values.

While more flexible than just providing multiple pre-defined complete cmdlines to select between, it is a more complex system to support with the validation logic having greater risk of flaws that would allow exploit of the trusted boot path. This this idea was thought not to have strong enough benefits to justify, compared to just providing alternate cmdlines.

The systemd version you checked that didn't have the feature you are asking for

No response