Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

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

 



On Tue, May 9, 2023 at 12:39 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Tue, May 9, 2023 at 12:31 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> 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.
>
> 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@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