On Tue, May 9, 2023 at 12:39 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering <mzerq...@0pointer.de> > wrote: > > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) 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. > > > > 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. > > > > Hence: btrfs subvols won't work for this > > If we're not using LUKS for encryption, then this is not a problem. > We're generally looking toward encrypting subvolumes individually > using the upcoming Btrfs native encryption capability rather than > using LUKS. That allows us to > > 1. Pick which subvolumes are encrypted > 2. Pick the security binding method per subvolume > > For example, the root and home subvolumes would use TPM or some other > non-interactive binding. The user subvolume in home would decrypt with > user login. > > While this is true, and it would be nice if we could just make "size of /boot" go away, if we can separate out "future of encryption" from "future of /boot", we're going to make our lives easier. And even if the preferred path for encryption for Workstation ends up being btrfs+fscrypt, that won't be the *only* path for Fedora and derivatives; another reason to try and sort this out independently. For the giant firmware problem, we have several ways to attack it: - Moderately increase boot/efi partition size as discussed here - Share firmware between multiple UKI's using system extensions (don't quite see how this works, but knowledgeable people think it should) - Use efifb at boot time (eliminates need for giant firmware, some possible regression of complicated screen scenarios) - Stop prompting for passphrases from the initrd (future of encryption, makes those regressions more palatable) Avoiding giant UKI's will likely also be a win from a performance point of view. - Owen
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
