Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams 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 certainly wouldn't suggest supporting multiple boot loaders with the
complexity level of grub.  sd-boot is quite a different beast though.
It is drastically limited in scope/features, with the actual loading
process offloaded to UEFI services, so probably better thought of as
merely a boot menu. It can't replace grub given its limited scope,
but it is not unreasonable to consider supporting it in parallel for
the cases where the kitchen sink is not required, since it makes it
massively easier to predict TPM measurements than grub.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux