On Thu, Sep 14, 2023, at 8:51 PM, Philipp Rudo wrote: > [...] > > In this context I hope it is also clear to you that when more and more > people rely on the spec you need a more formal process when including > changes. Especially when the change might break the implementation of > others. So no more making the .cmdline optional and allowing it to be > overwritten all on the same day. > > Having that said, what does "local override" exactly mean? Does that > mean a distro can allow a user to freely choose the cmdline without > checking any signatures? The behavior of systemd-stub is to allow the bootloader (or whatever called sd-stub) supplied cmdline when there is no .cmdline section in the UKI. That's how I understand "local override" here. For WIP v3 of this patch the behavior is to use the cmdline supplied by userspace to the kexec_file_load syscall if no .cmdline section is in the UKI. empty .cmdline section -> empty cmdline always passed to kernel .cmdline section -> use bootloader/user supplied cmdline (which would be empty by default) This setup does not make sense for a locked down / secure system though. Maybe the word "override" is not ideal. There is nothing actually being overridden as there is no cmdline in the UKI in the first place. sd-stub also allows the bootloader supplied cmdline if not using secure boot. So maybe the kernel could allow user supplied cmdline if not in lockdown mode for kexec maybe? If not in lockdown mode somebody can just kexec an unsigned kernel + unsigned cmdline using the kexec_load syscall anyways. For this case the word "override" makes sense. The logic for all of this in sd-stub is in [1]. > I.e. does that mean we can get rid of this > https://github.com/systemd/systemd/issues/24539 This is a different usecase IMO. >> Hence, seeing the spec as set in stone and as inherently low quality >> is the wrong way to see it I am sure. Instead, the goal here is to >> adjust the spec to make it work really nicely for *both* systemd and >> the kernel. > > Sorry, I never wanted to intend that the spec inherently low quality. > Just that it doesn't meat my expectations, yet. But that is fine. The > spec isn't even a year old and there's only a single implementation, > yet. So it's more documentation rather than a spec. Let's make it happen. [1] https://github.com/systemd/systemd/blob/5898cef22a35ceefa068d5f46929eced2baab0ed/src/boot/efi/stub.c#L140 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
