On Mi, 21.12.22 10:16, Chris Adams (linux@xxxxxxxxxxx) wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> said: > > Without an initrd we immediately have the following limitations: > > - all kernel modules needed to mount root must be compiled in > > - all that code is always loaded and remains in unswappable memory > > - root= syntax is limited to what the kernel understands, i.e. > > no root=UUID=… o root=/dev/disk/by-path/… or other udev links, > > no encryption or dm-verity. > > - no bluetooth keyboards or other fancy peripherals > > - recovery is pretty hard > > Also, the security lock-down for the kernel command line means: > - no network root filesystem > - no boot-time-only kernel/module configuration > > The idea of switching from grub2 to sd-boot would also drop network boot > and BIOS support. Supporting boot loaders seems to be a bit of a issue > sometimes, so trying to support multiple boot loaders seems like a bad > idea to me. I am not sure why you think that kernel command line lockdown would mean no network root fs anymore? I mean, sure, if you use the Fedora supplied vanilla signed UKI without anything else then it won't boot from a network, because that would be a security hole. But I see no reason why a network boot UKI couldn't be build that maybe be booted via PXE and derives root fs info from DHCP alone. (I mean, this is going to be as secure or insecure as your DHCP leases are protected, but the security is definitely not going to be worse than in the status quo ante that way) (you could also build/sign your own UKIs with the network boot info baked in. Or you could use TPM-bound systemd "credentials" to provide the network server info to the booted kernel securely) Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
