Hi Jan, On Thu, 14 Sep 2023 23:04:32 +0200 "Jan Hendrik Farr" <kernel@xxxxxxxx> wrote: > 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. Yeah, I expected that. The whole question was meant to be rhetorical. The point I wanted to make was that when a spec uses terms like "local override" it needs to explain what it means. Thanks Philipp > >> 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
