On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote: > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: >> >> > These are sort of "tautological" arguments. There must be some >> > objective reasons why this architecture was chosen instead of other >> > (i.e. using what already pre-exists). >> >> I think I misunderstood you in my earlier reply. I do not understand >> in what way you think my arguments are tautological. Can you >> elaborate? > > current Linux kernel has these features *already* in place: > > 1. CONFIG_EFI_STUB > 2. CONFIG_CMDLINE > 3. CONFIG_INITRAMFS_SOURCE > 4. Secure boot with MOK keys and .machine keyring to manage them. Well, you also have to add 5. CONFIG_CMDLINE_OVERRIDE 6. CONFIG_INITRAMFS_FORCE Otherwise the bootloader can supply an unsinged initramfs/cmdline and the kernel will use them. And then you do not get all the features. One of your earlier responses asks how a user might change the cmdline with UKIs. With UKIs all they have to do is create a small addon file and sign that (with their MOK if they are using a generic distro with shim, instead of using their own secure boot keys). With the bzImage alternative they would have to recompile the kernel. This was reason #1. Also what about #3? How would you pass PCR signatures using the normal EFI stub / bzImage? I can see how #4 is kinda tautological, but please don't dismiss the other arguments without even responding. > Given that every single feature in IKU does exists in some form in the > Linux kernel, I think it is fair to ask why scrape away this all > existing science and reinvent the wheel? No, not every single feature of *UKI*s exist in the linux kernel today. > If your reponse is "systemd", it is a tautological answerk, i.e. same > as sayig that "it is good because it is good". Not very motivating. Again for #4 I see the point, but what about #1 , and #3 (#2 is not that important, tooling can be fixed)? Also, do you see how your argument is basically: "The current way is better because it is the current way." I'm not trying to be snarky. But I'm coming from the perspective of a user that actually experienced a problem (not being able to kexec my UKIs) and trying to come up with a fix. I'm not trying to push something for the heck of it. Also the UKI spec at this point is not ready for the kernel, so this is not going in anyways right now. See the discussion on v2: https://lore.kernel.org/kexec/ZP+41JvEFjsnEG19@MiWiFi-R3L-srv/T/#t _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
