On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote: > On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > > On Sun, Jun 19, 2022 at 08:54:51PM -0000, Sharpened Blade via devel wrote: > > > Use unified kernel images by default for new releases. This can allow > > > for the local installation to sign the kernel and the initrd, so the > > > boot chain can be verified until after the uefi. Currently, the initrd > > > can be modified by attackers, so even if the / partition is encrypted, > > > the systems data can be read on the next boot. If the kernel image, > > > which includes the command line, and the initrd, is signed then it is > > > harder to comprimise the system. The system can still be comprimised > > > if the uefi is modified. > > > > > > If this was used, then the kernel could no longer be signed in the > > > package by the fedora infrastructure. > > > > I'd rather have fedora ship a unified + signed kernel image with a > > generic (aka 'dracut --no-hostonly') initrd instead of generating one > > on the local system. > > I think the issue with this is the initrd side blows out a lot, you > include all the firmware for all the modules in the system and then > you have 3 of them in /boot. > > I do wonder if it's possible to use multiple initrds, and maybe have > the firmware in a separate initrd shared between all installed kernels > if we go down this route. grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too. When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd. take care, Gerd _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
