On Wed, Oct 08, 2025 at 04:21:51PM -0400, Chris Murphy wrote: > > > On Sun, Oct 5, 2025, at 7:38 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Sep 22, 2025 at 07:54:16AM +0200, Simon de Vlieger wrote: > >> Note that Neal also has ideas to move XBOOTLDR into a btrfs subvolume > >> which for > >> many of the default editions and spins would remove the problem entirely. > > > > That's the "worst of both worlds" solution. It means that the boot loader > > thas to understand and fully access the the root volume, which means that > > the boot loader must have code to read the file system. When encryption > > is used, the boot loader must implement this too. This is all very > > constraining > > and fragile. >
> *shrug* (open)SUSE, macOS, and Windows do it this way. The > bootloader knows how to deal with encryption and root file system, > and get on with things. macOS and Windows do have dedicated recovery > partitions. macOS and windows are not a good example. Those systems effectively control the full stack and dictate what is supported and allowed, starting at the firmware level, through the boot loader, the OS, the file systems, etc. This is very different from us, where we support a wide range of machine types and have to work with the firmware written with the primary goal of supporting _other_ operating systems. (open)SUSE are closer to us, but they also do many strange things and arent' necesarilly a model to follow. I think we should argue based on merits, not by whether some other distro did something. In the other part of the thread Lennart lists various reasons why adding complex drivers and file systems in the boot loader is a maintainance burden and a big security risk. We currently aren't doing well at the security front… In fact, as long as we're using unauthenticated initrds, we can claim no protection whatsover against offline attacks. But, hopefully, we'll be moving towards more secure setups, and we should now not do steps that are moving us away from this goal and do things that we'll need to undo later. Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
