On Tue, May 9, 2023, at 12:31 PM, Lennart Poettering wrote: > On Di, 09.05.23 08:22, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > >> I've been asked to consider converting /boot to a Btrfs subvolume so >> that it no longer has a fixed space allocation to deal with the ever >> increasing amount of firmware required for NVIDIA GPUs[1]. This is >> currently incompatible with how systemd views the world, because the >> "discoverable partition spec" is wired to partitions, and there is no >> equivalent spec for subvolumes of a volume. And I imagine that >> XBOOTLDR (whatever that is) also would have a problem with this. > > This makese no sense. If you want /boot to just be a subvolume of the > rootfs btrfs, then this would imply it's also covered by the same > security choices, i.e. encryption. We want to bind that sooner or > later to things like TPM2, FIDO2, PKCS11. And that's simply not > feasible from a boot loader environment. Windows and macOS do this, so it is feasible, the question is what are the consequences of this and are we willing to live with them? One obvious consequence, it further creates dependency on a single bootloader, GRUB. Or we need an independent project that provides an EFI program for unlocking LUKS volumes within the pre-boot environment, thus making plaintext view available to any bootloader. > Hence, the place the kernel is loaded from (regardless if you call it > /efi or /boot or /boot/efi, and regardless what fs it is) must be > accessible from the boot loader easily, without requiring > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. I understand that might be difficult and something we don't want to do for resource reasons, but there isn't a technical impediment for it. > > Hence: btrfs subvols won't work for this > > A simple vfat partition however will. FAT isn't resizable. The growth requirement for /boot is greater for some use cases more than others, so there is pressure building because it will create waste for some use cases and underprovisioning in other use cases. Those unverprovisioned being told they can't upgrade but need to reprovision to solve this is kindof annoying. > >> Also, as an aside, there is now a "from-scratch" Btrfs EFI driver in >> development[2] (and for your personal horror, an NTFS one too[3]). > > Not sufficient. You'd also have to implement a LUKS EFI driver, and a > TPM2 EFI driver, and a FIDO2 EFI driver, and so on and so > on. Basically, you have to reimplement a good chunk of the Linux > kernel, of Linux userspace, systemd and so on in EFI mode. > > Good luck with that. Right. Hence Linux Boot. Dump all the toy drivers in favor of real ones. And a real user space. -- Chris Murphy _______________________________________________ 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
